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FOREWORD 


The  first  Multiplex  Data  Bus  Conference  was  held  In 
Dayton,  Ohio  3-5  November  l^lTb.  Its  Proceedings,  ASD-TR- 
76-22,  ADA-033793,  has  been  used  the  past  two  years  as  a 
primary  source  of  information  for  data  bus  designers. 
Significant  advances  In  systems  applications,  LSI  develop- 
ments and  the  preparation  of  MI L- STD- 1 S S 3B  have  prompted 
this  second  Multiplex  Data  Bus  Conference.  Maj  Gen  Too may. 
Deputy  Chief  of  Staff,  Development  Plans,  Air  Force  Systems 
Command,  requested  this  conference  being  hosted  by  the 
Aeronautical  Systems  Division,  Lt  General  Sylvester, 

Commander . 

The  purpose  of  the  conference  Is  to  exchange  data  on 
lessons  learned  from  system  applications,  present  new  LSI 
hardware  developments,  exploit  new  data  bus  technology  and 
present  test  methods  for  MIL-STD-1S53  multiplexed  data  buses 
between  the  U.S.  Air  Force,  Navy,  Army,  NASA,  Industry  and 
foreign  government s / Indus t ry . 

This  Is  the  FINAL  Volume,  Volume  II  of  the  2nd  Ml’X 
Conference.  Volume  I had  only  those  papers  that  reached 
us  In  time  for  printing  prior  to  the  conference.  To  pro- 
vide a better  reference  document,  this  FINAL  Volume  has 
reprinted  all  the  papers  from  Volxime  I and  also  reprinted 
MI L- STD- I 5 5 3B  with  the  typographical  errors  removed. 

Many  thanks  to  Malor  Robert  W.  Johnson  (AFSC/XRFl  for 
his  headquarters'  assistance  In  organlring  tills  conference 
and  also  to  the  ASD/ENAI  staff  who  assisted  In  organising 
the  technical  program,  proceedings  and  exhibits.  Captain 
Frederick  P e n s w o r t h and  Mr.  Harold  A 1 b e r . S p e c I .a  1 thanks 
to  Mr.  Allen  J.  Cannon  (ASD/CSl  who  did  an  outstanding  lob 
In  organizing  the  conference  facilities,  hotel  accommodations 
and  food  service. 


Thanks  also  to  the  moderators  and  all  the  speakers 
who  responded  with  outstanding  presentations  and  papers  In 
a timely  manner  despite  such  short  notice.  And,  finally  to 
my  secretary,  Mrs.  Marie  Jankovlcli,  for  her  expert  administra- 
tive help  In  handling  the  conference  correspondence  and  r e g 1 s - 
t rat  Ion . 
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highly  successful.  "sincrtheJrhirber*  ««* 

progress  In  this  area  and  widesorearf  i " ®*l^*’iiirsnt  technological 
U.S.  Military  Standard  Multiplex  Buf  M iVtt 

host  m follow«on  conference  In  1978.’  ^'STD-1553,  request  you 

In  your  17  December  1Q7a 

Conference  Recommendations."  you  pllJted^f^’  Bus 

TL  *"'"‘>P®«^®hlllty  can  only  r^s^U  k!  l^f^-cyde  savings 

•nd  sharing  lessons  learned  on  nn>iM  «xcrclslng  control  over 
on  conference  should,  therefore  stres buses.  This  follow- 
system  applications,  the  handbook  t^tJ 

Information  collected  during  the  iS^b  Jo?  «®ins  the 

srge  scale  integration  (LSI)  circuit  current 

bus  components.  The  on-going  work  to  multiplex  data 

upward  compatible  update  to  it  ba«Ia^  MlL-STD-1553  and  pro- 
should  also  be  presented.  these  experiences 
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CURRENT  DATA  BUS  APPLICATIONS 


MODERATOR:  John  R.  Cannon 
ASD/XRE 
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F-16  MULTIPLEX;  A SYSTEMS  PERSPECTIVE 


D.  E.  Sundstrom,  W.  B.  Anderson,  Jr.,  and  S.  A.  Alford 
General  Dynamics  Fort  Worth  Division 
Fort  Worth,  Texas  76101 

ABSTRACT 


The  F-16  avionic  system  is  integrated  via  a MIL-STD- 
1553  serial  digital  multiplex  data  bus.  The  architecture 
provides  a primary  and  backup  controller  within  a comple- 
ment of  nine  subsystems.  This  paper  addresses  the  control 
concept  and  implementation  of  the  data  bus  in  the  F-16  and 
provides  an  assessment  of  performance.  The  control  concept 
centers  on  the  criteria  to  be  used  for  access  to  the  bus, 
error  handling  procedures,  and  the  use  of  channel  redun- 
dancy. The  software-implemented  controller  has  proven 
efficient  in  design  (950  16-bit  words,  under  TL  duty  cycle) 
and  effective  in  error  control  (data  loss  rate  of  zero  over 
a 4-hour  period) . Analysis  of  flight  test  data  reveal  that 
systematic  sources  amount  for  virtually  all  data  bus  errors 
found  during  flight  testing. 


I.  INTRODUCTION 


The  F-16  initial  avionic  architecture  was  evolved  in 
the  1973-1975  time  frame;  in  this  period  a commitment  was 
made  to  implement  interface  data  transfers  by  means  of  a 
dual - redundant , serial  digital,  multiplex  data  bus.  Choice 
of  the  time-division  multiplex  bus  and  conformance  to  the 
then  evolving  military  standard^  offered  the  best  potential 
for  lightweight,  reliable  communications  and  long-term 
equipment  growth  compatibility. 


In  the  definition  phase,  critical  features  of  the 
avionic  architecture  were  settled:  each  sensor  would  con- 
tain its  own  specialized  processing,  backup  modes  of 
operation  were  defined,  and  a separate  fire  control  com- 
puter would  be  provided  to  integrate  sensor  data  and  pilot 
commands  into  a coordinated  fire  control  solution  2,3. 
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The  multiplex  controller  philosophy  was  settled  by  opting 
for  a simple  and  unambiguous  structure:  the  fire  control 
computer,  when  operating,  would  be  the  bus  controller;  if 
the  fire  control  computer  was  not  operating,  the  inertial 
navigation  unit  would  assume  bus  control.  In  addition,  the 
fire  control  computer  would  never  function  as  a terminal. 
These  decisions  enabled  interfaces  to  be  specified  and  con- 
tracts to  be  well-defined.  With  this  architecture  and 
system  philosophy,  the  full  scale  development  was  initiated 
in  early  1975. 


The  detailed  design  of  the  bus  control  algorithm  in 
the  primary  bus  controller,  the  fire  control  computer, 
proceeded  from  the  premise  that  "ability  to  communicate" 
was  the  criterion  to  be  used  in  redundancy  management,  i.e., 
selection  of  bus  channel  and  in  sensing  the  on/off /failed 
status  of  equipment  on  the  bus.  The  backup  control 
algorithm,  as  implemented  in  the  inertial  navigation  unit, 
was  considerably  simpler,  for  two  reasons.  First,  the  n\im- 
ber  of  data  blocks  to  be  managed  was  comparatively  small , 
and  second,  the  fault -reporting  and  error -recovery  proce- 
dure requirements  were  considerably  reduced.  In  this 
paper,  we  address  the  primary  bus  control  algorithm  imple- 
mented in  the  fire  control  computer,  with  mention  made  of 
the  backup  control  algorithm  in  appropriate  areas . 


Although  the  F-16  is  the  first  aircraft  to  employ  a 
MIL-STD-1553  compatible  multiplex  system,  it  is  not  the 
first  aircraft  to  use  a data  bus.  The  F-15^,  the  space 
shuttle^,  and  the  B-l^  all  utilize  1 MHz,  serial  digital, 
time  division  multiplex  buses.  All  of  these  vehicles 
preceeded  the  publication  of  the  initial  version  of  the 
military  standard  for  such  buses.  More  recently,  the  Air 
Force's  DAIS  project  has  utilized  the  successor  standard, 
MIL-STD-1553A,  to  integrate  communications  among  its 
elements  J - ^ 


The  military  standards  for  multiplex  systems,  while 
addressing  protocols  and  message  formats,  do  not  address 
the  mechanization  of  the  control  algorithm.  Hence,  there 
is  very  properly  room  for  considerable  variation  in  imple- 
mentations. The  F-16  Implementation,  described  herein,  is 
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characterized  by  low  processor  overhead  (Cl’U  duty  cycle  and 
core  utilization),  adaptive  configuring,  of  data  transfers 
to  reflect  the  conmunlcat  ivc  status  of  each  suhsysteni,  and 
efficient  and  effective  error  handling. 

The  paper  addresses  this  implementation  by  summarizing 
relevant  features  of  the  F-16  avionic  architecture  in 
Section  II,  the  bus  control  concept  and  interface  strategy 
in  Section  III,  and  the  primary  controller  imp  lenient  at  Ion 
in  Section  IV.  In  Section  V an  analysis  of  performance 
based  on  flight  test  data  is  provided.  Section  VI  contains 
a perspective  v^ew  of  the  controller  implementation  aiul 
suggests  testing  approaches  to  Identify  and  reduce  system- 
at Ic  error  sources . 


11.  F-lb  AVIONIC.  ARCUITF.CTUHK 

The  organization  of  data  flows  within  the  F-lb  archi- 
tecture may  be  viewed  in  several  ways.  The  physical 
interface  (Fig.  1)  Illustrates  the  electrical  ^nterconnec- 
t ions  . The  single  discrete  line  shown  provides  the  bus 
control  hand-off  cue  between  the  primary  controller  (FCC) 
and  the  backup  controller  (INU).  The  functional  interface 
(Fig.  '^)  illustrates  the  effective  data  flows  to  the 
various  equipments.  The  labels  identify  the  data  bU'cks 
which  are  transferred  between  elements;  each  data  block  and 
its  content  are  specified  in  a fornuil  Interface  control 
ilocument  . A summary  of  the  characteristics  of  tills  multi- 
plex traffic  is  proviiletl  in  Table  1. 

Tlie  architecture  of  t lie  F-lb  avionic  system  reflects 
basic  design  and  procurement  strategies,  both  of  which 
influence  the  design  and  operation  of  the  data  intercvimmu- 
nication  system.  An  underlying  architectural  concept  was 
that  each  sensor  should  do  its  own  local  processing,  this 
results  in  low  data  rates  on  the  bus  as  only  processed 
data  is  output  by  s sensor.  This  same  concept  r«'sul  t s in 
minimal  data  latency  as  transport  lags  cause».i  by  inter- 
mediate processing  are  eliminated.  A further  result, 
useful  in  procurement  and  development,  is  that  each  sub- 
contractor has  a well-bounded  task  so  that  demonst rat  ion 
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controller-to-subsystem  transfer,  which  requires  one 
comnand  word  and  one  status  word  in  addition  to  the 


data  block.  Type  2 is  a subsystem-to-controller  trans- 
fer, which  also  requires  one  command  word  and  one 
status  word  in  addition  to  the  data  block.  Type  3 is  a 
subsystem-to-subsystem  transfer  which  requires  two 
command  and  two  status  \«)rds  in  addition  to  the  data 
block. 


of  performance  and  problem  allocation  in  development  are 
clear  to  all  parties. 

All  equipments  at  present  operate  to  asynchronous 
clocks,  although  provisions  were  made  to  directly  synchro- 
nize the  FCC  and  HUD  processors.  Since  it  was  thought  in 
initial  design  that  synchronization  (or  at  least  periodic 
time  alignment)  might  be  needed,  the  controller  was  pro- 
vided with  a capability  to  command  all  terminal  clocks  to 
be  reset  simultaneously.  This  capability  is  not  presently 
used.  In  the  present  implementation,  the  truly  time- 
critical  data  comprises  inertial  platform  measurements . 
These  data  are  transmitted  with  a time-tag  so  that  users 
may  establish  the  latency  of  this  data. 

Overall,  the  benefits  of  asynchronous  processing  are 
primarily  simplicity  in  overall  control  strategy  and 
interface,  whereas  the  disadvantage  is  the  introduction  of 
variable  (random)  data  latency,  depending  upon  relative 
phasing  of  equipment  clocks.  In  applications  to  data  this 
variable  latency  has  not  proved  to  be  a problem.  In  the 
few  areas  where  latency  effects  ciin  be  noted  (primarily  in 
dynamic  displayed  data)  the  latency  can  be  removed  by 
appropriate  use  of  time-tag  or  by  algorithmic  compensation. 


III.  BUS  CONTROL  CONCEPT  AND  INTERFACE  STRATEGY 

There  are  two  keys  to  any  bus  control  algorithm  design 
(1)  the  predominant  transmission  mode,  whether  periodic  or 
on  demand,  and  (2)  the  error-handling  procedures.  In  the 
F-16,  a predominantly  periodic  interface  definition  was 
pursued.  This  greatly  facilitated  the  partitioning  of 
functional  requirements  among  contractors  and  minimal 
contractor-to-contractor  interface  sensitivities.  It  also 
enabled  a computer  program  structure  which  takes  advantage 
of  scheduled  inputs  and  outputs  to  minimize  data  latency. 
The  efficient  design  of  error-handling  procedures  is 
critical  to  the  overall  system  operation.  Error-handling 
in  the  primary  controller  was  implemented  in  the  flight 
program  software.  Here  again,  simplicity  provided  to  be 


the  key  that  assured  low  data  losses  without  the  consider- 
able overhead  that  could  he  consumed  by  elaborate  recovery 
proccdvjres . 

The  bus  control  and  interface  desipn  principles  are 
both  few  and  simple;  the  understanding,  of  these  principles 
leads  directly  to  an  effective  implementation. 

Ability  to  communicate  is  criterion  for  access  to  bus . 
Karly  discussions  focused  on  the  proper  criteria  for  access 
to  the  bus,  that  is,  when  should  the  controller  initiate 
communications  with  a terminal?  Some  proposed  solutions 
relied  on  status  discretes  from  each  subsystem;  receipt  of 
such  a discrete  would  indicate  readiness  to  communicate. 
Ultimately,  the  discretes  were  included  in  the  physical 
wirinp, , but  are  used  only  for  fault  reporting,  and  not  in 
any  way  utili;:ed  in  the  Inis  control  algorithm.  The 
algorithm  det ermines communicat ion  status  assessment  through 
periodic  polling  of  each  teminal.  Rased  on  the  results 
of  polling,  the  data  communications  to  a subsystem  are 
either  established  or  deleted.  If  a subsystem  responses 
to  a poll,  full  data  conmuinicat  ions  are  immediately  esta- 
blished in  the  controller's  current  command  table.  On  the 
otlier  hand,  if  a subsystem  fails  to  respond  to  a poll  lor 
two  consecutive  polling  periods,  the  appropriate  data 
transfer  commands  are  delete^!  from  the  controller's  current 
command  table.  This  periodic  pi'lling,  civii  inues  si'  that 
subsystem  communication  status  clianges  may  bo  discerned, 
without  reference  to  any  additional  input. 

Maintaining  communication  is  criterioii  for  jase ja t^  the 
redundant  chaiutel.  Kach  subsystem  is  connected  to  both 
channels  of  the  dual  bus  system,  bus  A and  Rus  R;  the  con- 
troller can  select  either  channel.  However,  botli  chant\els 
may  not  be  in  use  simultaneously.  Obviously,  many 
strategies  for  channel  selection  could  be  implemented. 

The  strategy  selected  is  one  of  t lie  simplest  : Tlie  con- 
troller uses  the  channel  that  worked  last  time.  For 
example,  if  a transfer  was  attempted  on  Rus  A and  was  stic- 
ci'ssftil,  the  next  transfer  of  the  same  block  would  also  lu' 
on  Rus  A.  Al  t ernat  ivel  V , if  an  attempt  on  Rvis  A failed 
(error  occurred)  then  a retry  of  that  transler  would  be 
attempted  on  Rus  R.  Consequently,  communications  with  a 
subsystem  will  migrate  to  the  channel  t liat  is  fvtnct  ion  inp, , 


Traffic  flows  are  constant  rate.  The  interface 
implemented  on  : he  F-16  calls  for  fixed  size  data  blocks 
transferred  at  predetermined  rates.  Once  communication  is 
established,  the  appropriate  data  blocks  are  transmitted. 

A few  data  blocks  art  specified  to  be  transmitted  on  an  'as 
required'  basis;  of  these  all  but  one  have  been  placed  on  a 
fixed,  slow-rate  basis.  The  remaining  'as  required'  block 
contains  inertial  system  position  update  data  and  is  only 
transmitted  v;hen  a position  update  is  accomplished.  Changes 
of  mode  or  event  occurrence  do  not  affect  traffic  rates,  but 
only  the  data  content  of  the  affected  blocks. 

Error  handling  must  be  efficient.  In  any  controller 
design  the  method  of  error  handling  is  a primary  concern. 

The  objective  of  error  handling  is  to  provide  the  communi- 
cation robustness  needed  in  real-world  environments. 

Errors  will  occur;  the  error  handling  scheme  must  be  an 
integral  part  of  the  bus  management  design.  Here  again, 
simplicity  prevails.  The  method  of  error  handling  imple- 
mented on  the  F-16  follows  this  procedure:  (1)  detected 
error  causes  software  interrupt,  (2)  software  marks  a log 
of  errors  and  either  retries  the  command  on  the  alternate 
bus  or  skips  the  command.  The  command  is  skipped  only  when 
the  retry  on  the  alternate  bus  failed.  This  method  may  be 
sunmarized  as  'fail  once,  retry  on  alternate,  fail  twice, 
go  to  next  command. ' 

Since  error  handling  is  so  important,  it  is  worth 
noting  that  several  strategies  were  examined.  In  parti- 
cular, a strategy  which  called  for  examining,  in  real-time, 
the  cause  of  the  error  and  then  deciding  action  was  con- 
sidered and  discarded.  The  reason  is  that  such  a strategy 
requires  excessive  computing  duty  cycle  to  implement  and 
yields  very  little  in  improving  communications  reliability. 

In  our  implementation  the  retry  is  limited  to  once  per 
command  (per  scan  of  the  command  table)  and  is  initiated  on 
the  alternate  bus.  The  retry  was  selected  to  be  on  the 
alternate  bus  in  favor  of  the  initial  bus  on  the  basis  of 
likely  error  source.  It  seemed  reasonable  (and  has  been 
justified  by  experience  as  shown  in  Section  V)  that  most 
errors  would  not  arise  from  random  noise  corruption  of  a 
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data  block,  but  rather  from  systematic  causes.  Candidate 
causes  would  include  timing  lock-outs  in  the  terminal 
hardware,  broken  or  intermittent  wiring,  faulty  coupling 
matrices,  or  KMI . Such  causes  would  be  likely  to  affect  one 
bus  more  than  the  o^ther  - hence  the  alternate  bus  retry 
strategy  and  the  consequent  migration  of  traffic  to  the 
working  channel. 


IV.  CONTKOhhKR  IMPLKMENTATION 

The  primary  bus  controller  is  implemented  in  the  soft- 
ware of  the  fire  control  computer.  This  computer  is  a 
Del  CO  M362F  machine  procured  for  the  F-16  and  programmed  by 
General  Pyn;inics.  The  Delco  ti362F  computer  includes  a bus 
control  communication  processor  which  operates  under  soft- 
ware control . This  processor  is  known  as  the  Serial  Data 
Interface  (SDI) . The  SDI , once  given  a start  command,  will 
read  and  execute  complete  bus  transfer  sequences  as  defined 
in  the  command  table.  Error  det ect  ion  is  also  provided  by 
the  SDI.  The  software  involvemeuL  comprises  (1)  initiating 
SDI  start  commands,  (2)  providing  error  interrvipt  handling, 
and  (3)  analyzing  poll  responses. 

Each  of  the  commands  (stored  in  main  computer  memory) 
cause  the  SDI  processor  to  either  initiate  data  trans- 
missions or  to  perform  an  internal  function  such  as  link 
(command  sequence  branch),  internal  self-test,  or  stop. 
Software  intervention  is  required  only  to  start  the  SDI 
processor  and  to  respond  to  SDI  initiated  interrupts.  Any 
bus  transmission  which  fails  to  complete  successfully 
causes  a "command  failure"  interrupt  to  be  generated  to  the 
CPU.  In  addition  to  this,  any  SDI  command  may  be  desig- 
nated so  that  a "command  task  complete"  interrupt  can  be 
generated  when  this  command  is  executed  by  the  SDI  pro- 
cessor. This  forced  interrupt  is  used  twice  per  FCC  minor 
frame  (1)  to  signal  the  FCC  software  when  key  input  data 
have  been  received  and  (2)  when  all  scheduled  transfers 
for  the  current  time  frame  have  been  completed.  The  SDI 
processor  is  commanded  to  initiate  a command  sequence  once 
per  20  millisecond  time  frame  (corresponds  to  50  Hz  rate). 
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The  avionic  Interface  Is  structured  Into  data  blocks 
whose  transfer  rate  Is  50  Hz  or  lower,  where  lower  rates 
are  powers  of  2 submultiples.  The  lowest  data  rate  Is 
1.5625  Hz.  At  present,  no  data  Is  transferred  at  the  3.125 
Hz  rate.  Within  this  structure,  the  command  sequence  in 
each  20  millisecond  minor  frame  interval  consists  of  data 
blocks  from  the  50  Hz  group  plus  those  blocks  from  one  of 
the  submultiple  groups.  Since  the  lowest  rate  is  1.5625  Hz, 
it  requires  6A0  milliseconds  (defined  to  be  a major  frame) 
to  complete  a full  data  transfer  sequence. 

To  implement  this  periodic  transfer  structure , the  SDI 
command  table  (Figure  3)  is  linked  prior  to  the  start  of 
each  minor  frame.  This  is  accomplished  by  setting  two  link 
conmands  to  provide  the  desired  path  through  the  command 
table.  The  command  sequence  has  been  structured  to  minimize 
data  latency  relative  to  the  processing  which  is  being 
executed  concurrently  by  the  CPU.  The  content  of  the 
command  table  is  modified  by  the  results  of  poll  processing 
to  contain  transfer-commands  for  only  those  subsystems 
which  are  actively  communicating. 

Polling  of  the  subsystems  by  the  controller  is  used  to 
selectively  configure  the  command  table,  deleting  transfers 
when  the  subsystem  is  not  communicating  and  restoring  trans- 
fers when  polling  response  indicates  an  active  subsystem. 
Each  subsystem  is  polled  on  each  channel  with  a dedicated 
function  command.  This  command  requests  the  addressed 
terminal  to  respond  with  its  current  status  word.  Any  poll 
command  which  fails  (either  due  to  a transmission  failure 
or  a fault  status  reported  by  the  addressed  system)  results 
in  a CPU  interrupt,  and  software  is  provided  to  record  the 
poll  command  failure.  The  results  of  the  subsystem  poll 
are  filtered  with  the  results  of  the  previous  poll  and  then 
used  to  configure  the  transmission  commands  in  the  command 
table,  according  to  the  criteria  given  in  Table  II. 

When  a poll  response  is  obtained  from  a subsystem 
which  had  previously  not  responded  (perhaps  powered  down) , 
transfers  with  that  subsystem  are  immediately  restored. 
Hence,  on  failure  or  power  down  of  a subsystem,  transfers 
are  restored  immediately.  Polling  is  accomplished  at  a 
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Table  II  BUS  SELECTION  RELATED  TO  POLL 
PROCESSING  RESULTS 

a.  ^ Control ler-to-Subsystem  and  Subsystera-to- 
Controller  Transfers 
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A FAIL 
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B FAIL 

A 
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NOTE  1 

b.  Subsystem-to-Subsystem  Transfers 
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NOTE  1 
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NOTE  1 

A 6:  B FAIL 

NOTE  1 

NOTE  1 

NOTE  1 

NOTE  1 1 
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NOTE  1. 


Bus  A selected  if  first  occurrence  of  double 
fault  or  crossed-bus  fault;  on  second  occurrence, 
the  affected  data  blocks  are  deleted  from  the 
command  sequence. 
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1.5625  Hz  rate  and  the  results  are  processed  iuxiediately 
following  poll  conpletion. 

We  draw  a distinction  betv;een  bus  nanagenent  and  fault 
reporting  for  avionic  maintenance.  As  can  be  seen,  the 
ability  to  conanunicate  criterion  is  sufficient  for  bus 
management.  The  polling  results,  of  course,  can  also  be 
used  in  assessing  the  need  for,  or  target  of,  maintenance 
actions.  We  accomplish  this  by  accumulating  the  poll 
results  in  a fault-reporting  software  routine.  This 
routine  combines  the  poll  failures  with  power  on  and 
installation  status  to  distinguish  between  true  failures 
and  power-off-or  not-installed  failures.  Those  results 
representing  true  failures  are  then  made  available  to  the 
pilot  and  maintenance  personnel. 

In  addition  to  poll  response  errors,  interrupt  soft- 
ware is  provided  to  respond  to  data  transmission  errors. 

The  error  handling  software  indexes  an  error  response  table, 
which  contains  an  entry  dictating  the  appropriate  error 
response  for  each  command.  For  data  transmission  failures, 
the  error  response  table  indicates  (1)  whether  the  command 
is  to  be  retried,  (2)  the  bus  to  be  used  for  the  entry  and, 
(3)  if  a data  storage  buffer  in  FCC  memory  should  be  narked 
as  invalid.  In  current  implementation,  all  data  trans- 
missions are  selected  for  immediate  retry  on  the  alternate 
bus.  However,  in  future  use  it  may  be  desirable  to 
selectively  retry  commands  or  to  retry  on  the  sane  bus  for 
subsystems  having  only  one  channel.  The  table  driven 
nature  of  the  interrupt  handler  has  provided  the  desired 
flexibility  in  error  response  without  an  unnecessary  burden 
on  the  CPU. 

The  resulting  implementation  utilizes  minimal  memory 
and  duty  cycle.  The  control  algorithm  consists  of  (1) 
normal  comands  to  start  the  bus,  (2)  an  interrupt  handler 
to  cue  the  selection  of  command  links,  (3)  an  error  inter- 
rupt handler,  (4)  a nodule  to  analyze  poll  results,  and 
(5)  the  bus  command  tables.  The  total  memory  utilization 
is  950  16-bit  words,  while  the  CPU  processing  utilizes  less 
than  2%  of  the  machine  duty  cycle.  Error  rates  are 
sufficiently  low  (see  Section  V)  that  error  handling  adds 
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negligible  processing  overhead.  Typical  error  response 
times  are  118  microseconds  for  first  failure  of  command, 
122  microseconds  for  second  failures,  and  93  microseconds 
for  a poll  failure. 


V . PERFORMANCE 


The  first  flight  of  an  F-16  with  an  operating  multiplex 
bus  aboard  was  on  12  August  1976.  Since  that  date,  over  500 
avionic  flights  have  been  made.  The  accumulated  experiences 
of  the  flight  test  environment  demonstrate  clearly  the 
robustness  of  the  controller  design  in  response  to  extreme 
ranges  of  error  and  fault  conditions.  In  this  section,  we 
describe  qualitatively  some  of  the  anomalous  conditions 
encountered  and  also  provide  a quantitative  analysis  of  in- 
flight error  rates . 

The  analysis  of  in-flight  events  is  made  possible 
through  a flight  test  instrumentation  system  which  can 
eavesdrop  on  both  buses.  The  instrianentation  system  can 
record  up  to  90  minutes  of  multiplex  data  on  multi-channel 
magnetic  tape.  A ground  based  computer  is  used  for  post- 
flight processing  of  data  recorded  by  the  instrumentation 
system.  The  data  processing  system  can  provide  either  raw 
data  or  can  selectively  extract  information  from  the  total 
data  set.  For  example,  a computer  report  of  only  those 
messages  to  and  from  a particular  system  may  be  prepared  or 
a report  of  only  incomplete  or  erroneous  messages  may  be 
made , 

To  further  provide  performance  data,  two  error  counters 
were  implemented  as  an  integral  part  of  the  controller  soft- 
ware. Each  time  a particular  message  must  be  retried,  due 
to  any  type  of  error,  the  single-error  counter  is  incre- 
mented. Each  time  a particular  message  fails  to  be  trans- 
acted properly  on  the  retry,  the  double-error  counter  is 
incremented.  These  two  counters  provide  an  accurate 
measure  of  data  block  error  rates.  Subsequent  analysis 
of  raw  data  at  the  time  one  or  both  of  the  counters  is 
incremented  can  indicate  the  specific  nature  of  a failure, 
e.g.,  not  enough  words  transmitted,  no  status  response, 
status  reponse  with  error  bit  set,  etc. 
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In  terras  of  qualitative  performance,  the  flight  test 
environraent  has  provided  a considerable  variety  of  instances 
in  which  controller  response  is  of  interest.  In  each  of  the 
situations  described  below  the  controller  operated  as 
designed,  providing  a maximum  degree  of  communications 
integrity . 

o Failed  terminal  on  the  primary  bus.  Fault 
detected  by  controller,  appropriate  subsystem 
data  switched  to  alternate  bus.  Mo  loss  of 
communications.  Fault  reported  to  mainte- 
nance crew  through  self-test  software. 

o Failed  terminal  on  alternate  bus.  Fault 
detected  by  analysis  of  poll  responses. 

Data  remains  on  primary  bus . No  loss  of 
communication.  Fault  reported  to  main- 
tenance crew  through  self-test  software. 

o Double  bus  failure  to  one  subsystem.  Loss 
of  subsystem  communication;  retries 
unsuccessful.  Poll  responses  analyzed  and 
faulted  subsystem  isolated  from  data 
stream.  Period  i.e.,  polling  maintained 
to  assess  subsystem  status.  Self -test 
software  verifies  that  subsystem  povjer 
is  on  prior  to  reporting  the  fault  to  the 
pilot . 

o Intermittent  double  bus  failure  to  one 
subsystem.  Retries  generally  unsuccess- 
ful. Loss  of  communication  if  failure 
persists  through  two  polling  periods, 
resulting  in  isolating  subsystem  from  data 
stream.  Communications  re-established  as 
soon  as  response  to  poll  is  obtained.  If 
subsystem  power  is  on,  self-test  software 
reports  fault  to  pilot,  identifies  as 
intermittent . 

o Mismatched  switching  matrix  (prototype) . 

Resulting  high  noise  and  degraded  signal 
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waveform  created  high  error  rate  situation. 
Retries  successful  to  the  point  that  no 
external  performance  degradation  was  dis- 
cemable.  False  reports  of  subsystem  bus 
failures  together  with  garbled  instrumen- 
tation data  led  to  the  identification  of 
the  problem  and  its  source, 

o Concurrent  bus  traffic  on  a single  bus. 
Arose  when  terminal  wrongly  interpreted  a 
specific  data  word  to  another  subsystem 
as  its  terminal  address  and  initiated  a 
data  output.  Controller  detected  event 
as  an  incorrect  word  count  error,  shifted 
erred  block  to  alternate  bus  and  retried. 
Retry  successful  because  timing  lockout  in 
faulty  terminal  inhibited  response.  Next 
regular  transmission  of  this  block  resulted 
in  same  error,  overcome  by  same  process. 

No  loss  of  communication . Problem  dis- 
covered by  post-flight  instrumentation 
data  analysis. 

o Two  terminals  respond  to  the  same  address. 
Arose  when  a broken  wire  in  one  terminal 
resulted  in  an  effective  change  of  terminal 
address.  Unfortunately,  another  terminal 
also  owned  that  address.  Faulty  terminal 
then  competed  with  rightful  terminal  in 
acknowledging  commands  and  transmitting 
data.  Poll  analysis  identified  double 
bus  failure  to  faulty  terminal . Strange 
in-cockpit  behavior  of  faulted  subsystem 
made  problem  evident  to  ground  crev;, 

o One  terminal  could  not  accomplish  two  back- 
to-back  transmissions  on  the  same  bus.  A 
design  flaw  in  early  hardware  associated 
with  this  subsystem  resulted  in  locking  out 
transmission  of  a data  block  which  iiiine- 
diately  followed  transmission  of  a somewhat 
longer  data  block.  Retry  of  the  second 
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blocl;  was  successful.  The  next  sequential 
transmission  was  initiated  (as  normal)  on 
the  A bus  and  was  successful.  The  result 
was  that  this  subsystem’s  outputs  were 
channeled  in  an  A,  B,  A sequence.  No 
communication  loss,  no  fault  reported. 

The  problem  was  discerned  and  identified 
through  post-flight  error  analysis. 

o Inconsistent  status  word  content.  An 
early  design  flaw  in  one  subsystem  lead 
to  a situation  in  which  the  status  word 
produced  by  this  subsystem  had  content 
which  varied  depending  on  the  type  of 
command  received.  Specifically,  if  a 
dedicated  function  command  was  received, 
the  terminal  hardware  immediately  responded 
with  a canned,  valid  status  word.  If  the 
command  involved  data,  however,  the  content 
of  this  status  word  was  read  from  the  CPU. 

The  trouble  arose  when  the  subsystem 
faulted  and  set  the  terminal  status  bit 
bad.  This  resulted  in  double  errors  on 
all  retries,  and  hence,  total  loss  of  data 
communication  with  this  subsystem.  At 
poll  time,  however,  the  terminal  would 
respond  as  healthy.  It  was  clear  from 
in-cockpit  behavior  that  the  subsystem  was 
effectively  dead,  yet  the  avionic  self- 
test fault  reporting  did  not  indicate  the 
suspected  double  bus  failure.  On-line 
analysis  with  an  oscilloscope  solved  the 
mystery. 

To  provide  a quantitative  assessment  of  performance  we 
have  evaluated  error  rates  on  four  recent  F-16  flights. 

The  airplanes  were  F-16A  No.  3 and  F-16B  No.  1;  both  were 
built  and  flown  as  part  of  the  F-16  full-scale  development 
program.  The  instrumented  airplanes  had  the  same  comple- 
ment of  avionics  equipment,  consisting  of  full-scale 
development  and  pre-production  hardware.  Of  the  nine 
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possible  subsystems,  only  the  Target  Identification  Set  was 
not  installed.  The  data  rates  expressed  in  Table  III  repre- 
sent the  multiplex  traffic  generated  by  this  avionic  con- 
figuration . 

The  error  data  summarized  from  the  analysis  is  provided 
in  Table  IV.  The  conditions  we  required  in  selecting 
analysis  intervals  were  (a)  all  installed  subsystems 
operational  (b)  the  airplane  be  airborne.  V7ithin  these 
constraints  we  extracted  the  intervals  displayed  in  the 
Table.  Since  a tj^Jical  flight  is  of  one  hour  airborne 
duration,  these  intervals  represent  the  steady-state 
multiplex  performance.  In  addition,  no  intervals  were 
selectively  discarded  to  eliminate  errors . The  above  two 
criteria  were  the  only  selection  criteria. 

Two  features  immediately  stand  out  from  inspection  of 
the  Table.  First,  the  obvious  difference  in  single-error 
counts  between  the  two  airplanes.  Second,  the  low  number 
of  double-error  counts  experienced  on  all  flights.  Taken 
together,  these  features  indicate  the  strong  reliability 
of  the  avionic  multiplex  system.  Summing  the  count  of 
double  errors  together  with  the  flight  durations  on  all 
four  flights,  we  obtain  the  result  that  the  data  loss  rate 
was  zero  over  a period  of  273  minutes. 

Returning  to  the  differences  between  the  single-error 
rates  on  the  two  aircraft,  a detailed  analysis  of  error 
distribution  in  time  as  well  as  inspection  of  raw  trans- 
action data  provided  insight  into  the  error  source. 

A once-per-second  report  of  the  bus  controller  error 
counters  during  flight  241  of  F-16A  No.  3 revealed  that 
the  retry  counter  was  incremented  nearly  once  each  printout, 
i.e.,  the  errors  appeared  "uniformly"  distributed  across 
the  entire  sample  period.  (The  computed  average  error 
rate  was  actually  0.79  errors  per  second.) 

Analysis  of  raw  data  fror,":  selected  time  intervals  dis- 
closed the  presence  of  a highly  systematic  error  condition. 
Ten  message  anomalies  which  caused  the  error  counter  to  be 
incremented  were  isolated.  In  nine  of  the  ten  cases 
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Table  IH  FLIGHT  TEST  DATA  RATES 


Date  Block  Rate:  956,25  blocks  per  second 

Safe  Block  Rate:  382 . 8125  blocks  per  second  (Note  1) 

Total  Block  Rate;  1339.0625  blocks  per  second  (Note  2) 


Total  Word  Rate;  14,405  words  per  second  (Note  3) 


NOTES 

1.  Safe  blocks  consist  of  a dedicated  function 
command  and  the  associated  status  word  response. 
These  blocks  are  inserted  into  the  command 
streat  following  every  subsystem-to-subsystem 
transfer.  They  assure  that  the  receive  in  such 
a transfer  will  be  reset  in  the  event  that  the 
transmitter  did  not  send. 

2.  Represents  the  total  data  stream  on  which  errors 
are  counted;  polling  blocks  are  excluded  from 
the  error  count. 

3.  Includes  command,  status,  and  data  woras 
associated  with  data  and  safe  blocks;  polling 
blocks  excluded. 


examined,  one  particular  subsystem  failed  to  respond  wit  a 
status  word  after  beinp,  commanded  to  receive  a seven  word 
data  block  by  the  controller.  Tlie  retry  on  (be  alternate 
bus  was  successful  in  every  case.  Further  investigation 
disclosed  that  the  status  response  error  occurred  only  when 
the  received  comnund , which  is  executed  once  eacli  80  milli- 
seconds, followed  a controller  polling  sequence,  which 
occurs  only  once  each  640  milliseconds.  The  interaction  of 
the  polling,  sequence  with  the  receive  command  clearly 
"induced"  the  predominate  error  condition  observed  on  F-16A 
No.  3.  (I'he  other  anomaly  discovered  in  the  raw  data  was  a 
failure  of  another  subsystem  to  respond  to  a command  to 
receive  two  data  words  from  (he  controller.  Apain,  (lie 
retry  on  the  alternate  bus  was  successful.') 


These  data  provide  insipht  into  the  typical  types  of 
errors  which  have  been  experienced  on  the  F-16  multiplex 
system.  The  ov^erwhelminp,  majority  of  errors  have  been 
systematic,  attributable  primarily  to  teniiinal  desipn  flaws. 

Within  this  catepory,  the  most  common  error  lias  In'en 
failure  of  a receivinp  terminal  to  acknowledpe  receipt  of 
data,  i.e.,  no  receiver  status  word  was  t ransmi  t ( eii . iMi  t lie 
other  hand,  we  have  yet  to  find  a s tuple  error  v»'liicli  cleaVlv  j 

represented  a sipnal  corruption  by  bacUpround  noise.  These  j 

factors  lead  to  t houpht  s about  ruiltiplex  improvements,  dis- 
cussed in  the  followinp  section.  i 


Returninp  to  t lie  tiata  of  Table  IV'.  we  have  calcul.iti'd 
two  error  rates  associated  with  each  flipht  . InU  li  the  woni 
and  bit  error  rates  must  be  interpreted  as  equivalent  ervv'v 
rates,  since  the  errors  actually  coutit  ed  are  on  a block 
basis.  That  is,  v;e  assumed  that  a block  error  is  etpiiv.i- 
lent  to  a sinple  word  or  sinple  bit  error.  \>?liicli  is  not 
necessarily  true.  In  fact,  the  true  bit  error  rate  is 
considerably  better  tlian  the  data  would  indicate,  simply 
because  we  know  that  most  of  the  errors  are  associated 
with  protocol  defaults  (missinp  status  words'). 

VI.  SYSTKM  DKSTdN  rMRSTFCTT VF.S 


1 
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The  distillation  of  the  F-l6  multiplex  system  desipn 
and  evaluation  experiences  lea  its  us  to  tvoo  perspectives. 


First,  the  design  principles  as  described  in  Section  II 
provide  a sound  basis  for  bus  controller  implementation. 
Second,  the  systematic  error  modes  that  dominate  noise 
errors  suggests  that  specific  testing  beyond  that  required 
by  the  multiplex  standard  should  be  explored.  A brief 
expansion  of  these  perspectives  is  provided  in  this  section. 

Our  bus  control  concept  focused  on  maintaining  commu- 
nication among  the  subsystems.  The  implementation  of  this 
concept  required  but  minimal  core-the  950  words  include  the 
command  tables  - and  very  low  execution  time.  Of  equal  or 
greater  importance  is  the  efficacy  of  the  error  handling 
implementation.  It  is  not  only  extremely  effective  in 
terms  of  data  block  transfer  but  also  accomplished  the 
error  handling  with  negligible  processing  time. 

The  transition  logic  which  causes  bus  controller 
responsibilities  to  be  transferred  between  the  primary  and 
backup  control  is  simple  and  effective.  It  has  been 
exercised  extensively  in  both  directions.  The  avionic 
system  gracefully  transitions  to  and  from  its  backup  mode 
of  operation  when  the  bus  control  logic  in  the  inertial 
navigation  unit  is  selected  and  deselected.  In  the  lab, 
failure  of  the  bus  control  discrete  has  been  simulated.  In 
this  mode,  principally  because  of  low  duty  bus  cycle,  the 
system  displays  can  be  observed  to  rapidly  alternate  between 
primary  and  backup  display  modes.  (This  condition  may  be 
overridden  by  powering  down  one  of  the  two  controllers.) 

No  unintentional  instances  when  more  (or  less)  than  one 
controller  has  been  active  simultaneously  have  occurred 
during  two  years  of  the  flight  testing  of  the  F-16. 

Our  flight  test  and  laboratory  experience  showed  that 
systematic  error  modes  predominate  in  the  operation  of  the 
integrated  system.  Two  important  points  regarding  system- 
atic errors  should  be  made.  First,  no  degradation  of 
avionic  system  performances  was  discernible  during  the 
flights  when  systematic  errors  occurred  frequently.  This 
is  a testimony  to  the  robustness  and  spontaneity  of  the 
bus  control  algorithm  in  providing  high  communication 
integrity  in  the  presence  of  multiple  errors.  Second,  the 
subsystems  which  caused  the  systematic  errors  had  passed 


system  operator,  Despite  systematic  error  conditions,  data 
loss  has  proved  to  be  negligible  (no  data  loss  is  over  four 
hours) . This  implementation  of  a MIL-STD-1553  multiplex 
bus  has  been  shovm  to  provide  a very  satisfactory  avionic 
system  communication  network. 
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ABSTRACT 

This  paper  presents  a brief  description  of  the  LAMPS  MK-III  system  and  its  management, 
and  a more  detailed  description  of  the  MK-III  Airborne  System.  It  summarizes  the  inter- 
pretation of  MIL-STD-1553A  as  applied  to  LAMPS  MK-III  and  describes  the  software  ap- 
proach to  bus  controller  lO. 


INTRODUCTION 

The  most  evident  feature  of  the  Light  Airborne  Multipurpose  System  (LAMPS)  is  the  com- 
bination of  a helicopter  and  a destroyer.  LAMPS  is,  in  a real  sense,  a destroyer  system 
which  dramatically  extends  the  range  of  the  destroyer’s  sensors  and  weapons . 

The  newest  version  of  LAMPS,  the  MK-III  system,  is  now  in  full  scale  development.  Suc- 
cessful completion  of  technical  and  operational  testing  of  the  full  scale  development  system 
is  necessary  before  the  decision  can  be  made  to  proceed  with  production.  The  decision  to 
produce  is  scheduled  for  1981,  and  the  first  operational  MK-III  LAMPS  should  appear  in 
the  fleet  in  1984. 

The  MK-III  LAMPS  is  a integrated  ship-air  system  in  which  the  shipboard  and  airborne 
elements  communicate  over  a two  way  directional  digital  data  link.  The  normal  method  of 
operating  LAMPS  will  require  the  close  coordination  of  both  shipboard  and  airborne  equip- 
ment and  operators.  However,  the  airborne  system  and  crew  can,  if  necessary,  operate  in- 
dependently. 


A new  and  saiiciit  feature  o'  the  arcLitecture  of  the  MK-II!  airborne  system  is  the  use  of 
digital,  command/response,  time  division  multiplexing  to  interconnect  the  avionic  sub- 
systems; i.e.,  the  use  of  a 1553A  data  bus. 

The  Navy’s  manager  of  this  system  finds  himself  in  an  unusual  dual  role.  He  is  both  an  Air 
Project  Manager  and  a Ship  Project  Manager,  and  is  designated  PMA/PMS-266.  The 
system  prime  contractor  is  the  Federal  Systems  Division  of  the  IBM  Corporation.  The  SH- 
60B  helicopter  is  being  provided  to  the  Navy  by  the  Sikorsky  Aircraft  Division  of  United 


Technology  Corporation.  PMA/PMS-266  has  engaged  the  resources  of  three  Navy  ac- 
tivities to  conduct  independent  testing  of  system  software  and,  later,  to  provide  software 
maintenance  when  the  LAMPS  MK-III  Is  In  the  fleet.  These  Navy  activities  are;  the  Naval 
Air  Development  Center  In  Warminster,  Pa;  the  Naval  Underwater  Systems  Center  in  New 
London,  Conn;  and  the  Fleet  Combat  Direction  Systems  Support  Activity  in  Dam  Neck, 

Va. 

DESCRIPTION  OF  THE  LAMPS  AIRBORNE  SYSTEM 

The  airborne  system  consists  of  the  seven  subsystems  illustrated  in  figure  1: 

1.  Anti-Submarine  Warfare 

2.  Ordnance  Launch  Control 

3.  Communication 

4.  Data  Handling 

5.  Anti-Ship  Surveillance  and  Targeting  (ASST) 

6.  Navigation 

7.  Data  Display 

Two  important  sensors  do  not  appear  in  figure  1 since  they  are  not  connected  to  the  data 
bus.  They  are  the  Magnetic  Anomaly  Detection  (MAD)  sensor  and  the  radar. 

Ten  Remote  Terminals  connect  these  subsystems  to  the  data  bus  and,  thus,  to  a central 
computer/bus  controller.  The  LAMPS  data  bus  uses  only  two  of  the  three  types  of  data 
transfer  allowed  by  MIL-STD-1553A.  Controller  to  Remote  Terminal  (RT)  transfers  and  RT 
to  controller  transfers  are  employed.  RT  to  RT  transfers  are  not  used.  This  reduces  the 
software  sophistication  necessary  to  control  the  bus. 

Bus  control  is  provided  by  one  of  two  AN/AYK-14  Standard  Airborne  Computers  used  in 
LAMPS.  This  central  system  computer.  Standard  Airborne  Computer  1,  also  provides  the 
computation  and  control  required  to  perform  all  mission  related  airborne  functions  and  to 
integrate  the  avionic  equipment  into  a cohesive  system.  All  LAMPS  signal  procesisng  is 
performed  at  the  subsystem  level. 

Standard  Airborne  Computer  2,  a slightly  different  configuration  of  the  AN/AYK-14.  is 
used  as  a remote  terminal  in  the  ASST  subsystem  to  process  Electronic  Warfare  sensor 
signals.  If  Standard  Airborne  Computer  1 fails,  its  computer  program  would  be  loaded 
from  the  Magnetic  Tape  Memory  into  Standard  Airborne  Computer  2.  Electronic  Warfare 
would  no  longer  be  processed,  and  Standard  Airborne  Computer  2 would  serve  as  the  bus 
controller  in  a degraded  system  mode.  Acoustic  Signal  Processing  is  performed  in  the  Ad- 
vanced Signal  Processor  (ASP)  within  the  Analyzer  Detecting  Set.  This  processor  is  yet 
another  standard  Navy  computer.  The  ASP,  once  called  PROTEUS  , is  not  connected  to 
the  1553 A bus. 

There  are  two  1553 A data  bus  channels  in  the  MK-llI  air  system;  Channel  1 and  Channel 
0.  Channel  1 is  used  as  a program  load  path  and  a data  extraction  path,  and  connects  the 
two  AN/AYK-14  computers  to  the  Magnetic  Tape  Memory.  This  channel  is  implemented 
with  redundant  busses;  Bus  A and  B.  Selection  of  the  bus  to  be  used  by  Channel  1 is  a bus 
controller  software  function.  Channel  0,  consisting  of  a single  bus,  is  the  communication 
path  between  the  bus  controller  and  RT’s  of  the  avionic  subsystems.  Cost  was  the  primary 
factor  in  the  decision  not  to  provide  bus  redundancy  for  channel  0.  Channel  0 is  approx- 
imately 80  feet  long. 
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Figure  1 - Computer  Interface  Block  Diagram 


The  Magnetic  Tape  Memory  was  placed  on  a separate  channel  so  that  even  if  the  system 
bus  (channel  0)  gets  tied  up,  the  computer  program  for  Standard  Airborne  Computer  1 stilt 
can  be  reloaded  and  the  system  reinitialized. 

The  ASP  is  connected  to  Standard  Airborne  Computer  1 by  a Proteus  Digital  Channel 
(PDC)  rather  than  by  the  data  bus.  The  primary  reason  for  this  is  that  at  the  time  the 
system  was  designed,  the  ASP  was  in  the  late  stages  of  development,  and  did  not  include  a 
1553A  interface.  On  the  other  hand,  the  AN/AYK-14  computer  was  in  the  early  stages  of 
development,  and  the  incorporation  of  a PDC  interface  was  feasible. 

The  remote  terminals  and  Standard  Airborne  Computer  1 also  communicate,  in  parallel  to 
the  1553 A bus,  via  the  discrete  channel.  This  channel  provides  an  independent  path  by 
which  the  computer  can  issue  a master  clear  signal  to  any  terminal,  and  provides  a method 
for  the  remote  terminals  to  report  their  power  on/off  status. 

DESCRIPTION  OF  THE  LAMPS  APPLICATION  OF  THE  1553A  BUS 

IBM  has  issued  a detail  specification  (IBM  62261 14C)  which  defines  the  requirements  and 
characteristics  of  the  interface  between  the  LAMPS  data  bus  and  an  avionic  subsystem.  It 
is  intended  to  amplify  and  interpret  MIL-STD-1553A.  The  standard  defines  transmission 
word  formats  for  command,  data,  and  status  words. 

Figure  2 illustrates  the  command  word  format.  M1L-STD-1553A  reserves  only  one  value  of 
the  mode  control  code  associated  with  the  Subaddress/Mode  (SAM)  field  (the  value  00000). 
All  Subaddress/Mode  field  values  used  in  the  LAMPS  system  are  shown  in  f’gure  2.  When 
the  Subaddress/Mode  contains  the  value  00000,  that  implies  that  the  Data  Word  Count 
field  does  not  contain  a word  count.  Rather,  it  contains  additional  mode  control  informa- 
tion. 

The  assignment  of  the  32  values  of  this  auxiliary  mode  control  field  is  shown  in  figure  2. 
MIL-STD-1553A  again  reserves  the  use  of  the  value  00000,  in  this  case  to  signify  dynamic 
bus  allocation.  The  MK-III  system  does  not  employ  dynamic  bus  allocation,  but  the  assign- 
ment is  included  here  for  completeness. 

Where  the  bus  controller  has  transmitted  a command  word  with  the  Subaddress/Modc  field 
set  to  zero  and  the  word  count  field  set  to  two,  signifying  a “Transmit  Status  Word”  com- 
mand, the  remote  terminal  addressed  would  respond  with  a Remote  Terminal  Status  Word. 
Figure  3 shows  the  LAMPS  version  of  the  RT  Status  Word.  It  is  as  specified  in 
MIL-STD-1553A,  with  the  LAMPS  assignments  of  the  bits  in  the  Status  Code  field 
shown. 

If,  the  bus  controller  had  issued  a command  word  with  the  Subaddress/Mode  field  set  to 
two  and  the  word  count  field  set  to  one  (the  command  to  send  one  “RT  Built-in-test  Status 
Word”)  the  RT  addressed  would  respond  with  an  RT  Status  Word  followed  immediately  by 
an  RT  BIT  Status  Word.  The  RT  BIT  Status  Word  is  a uniquely  defined  Data  Word.  The 
structure  of  an  RT  BIT  Status  Word  is  shown  in  figure  4.  This  word  provides  a method  for 
a Remote  Terminal  to  report  specific  faults  in  data  bus  message  traffic,  and  to  provide 
more  detailed  information  regarding  subsystem  and  subsystem  element  status. 

A Message  Error  field  h^s  been  defined,  and  the  significance  of  bits  within  this  field  is 
shown.  When  a bit  is  set  in  this  field,  the  Remote  Terminal  will  also  set  the  Message  Error 
bit  in  the  RT  Status  Word.  The  remaining  16  bits  are  associated  with  subsystem  faults, 
and  are  found  in  two  fields.  The  information  in  these  fields  is  uniquely  defined  for  each 
Remote  Terminal.  Fault  indications  in  these  subsystem  fields  will  cause  the  Terminal  Flag 
(T/F)  bit  in  the  RT  Status  Word  to  be  set. 
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Sinct^  th**  RT  BIT  Status  Word  is  a Data  Word,  the  1553A  srheme  permits  as  many  of 
these  words  as  is  required.  The  number  of  BIT  Status  Words  varies  from  RT  to  RT.  and 
depends  on  the  amount  of  fault  information  associated  with  the  equipment  connected  to 
the  RT.  As  currently  designed,  the  greatest  number  of  BIT  Status  Words  that  the  bus  con- 
troller sees  In  response  to  a BIT  Status  command  is  four. 

Figures  5.  6.  and  7 show  representative  sequences  of  commands  used  in  LAMPS.  In- 
itialization. Data  Transfer  and  Self  Test  sequences  for  the  airborne  data  link  terminal 
(Radio  Terminal  Set)  are  illustrated.  In  the  Initialization  and  Data  Transfer  sequences  the 
Control  Command  Data  Transfer  Command  Word  is  employed  to  transfer  a Data  Word 
containing  control  information  for  the  data  link.  This  information  includes  the  selection  of 
the  forward  or  aft  data  link  antenna,  and  further,  tells  that  antenna  the  relative  iK’aring  at 
which  to  point  In  order  to  aim  at  the  destroyer. 

The  computer  program  used  in  Standard  Airborne  Computer  1 during  a LAMPS  mission  Is 
called  the  Avionics  Operational  Program  (AOP).  The  AOP  includes  an  algorithm  that  con- 
trols the  periodic  communication  between  the  computer  and  the  remote  terminals. 

Figure  8 shows  the  pulling  frequency  and  I/O  rates  for  each  of  the  RT's.  The  I/O  protocol 
between  Standard  Airborne  Computer  1 and  any  RT  is  based  on  a 40  millisecond  cycle.  It 
can  be  seen  from  figure  8 that  each  device  on  channel  0 has  a polling  rate  which  is  a multi- 
ple of  forty  milliseconds.  Each  40  millisecond  cycle  is  subilivided  into  a polling  perltxl  ami 
a data  transfer  period.  The  periling  period  occurs  at  the  start  of  the  cycle  and  Involves 
transmission  of  a transmit  status  word  command  to  each  RT  scheduled  to  be  accessed  dur- 
ing this  particular  40  millisecond  cycle.  During  the  polling  sequence,  the  RT  Status  Word 
will  be  examined  for  the  state  of  bits  controlling  subsequent  data  transfers  to  and/or  from 
each  RT.  After  completion  of  polling  operations,  data  transfer  will  commence.  During  the 
data  transfer  period,  each  RT  scheduled  for  data  transfer  activity  will  Ire  commanded  to 
send  and/or  receive  data  from  Standard  Airborne  Computer  1.  After  completion  of  all  data 
transfer  activity,  the  data  bus  will  remain  in  a quiet  state  until  the  start  of  the  next  40 
millisecond  cycle. 

The  number  of  data  transmit  commands  is  thereby  reduced  to  the  number  of  remote  ter- 
minals that  actually  have  data  available  for  transmission.  Simulation  studies  performed  by 
the  prime  contractor  indicate  that  the  average  data  bus  utilization  is  17  percent  of  capaci- 
ty. and  that  the  peak  load  is  29  percent  of  capacity. 

AH  LAMPS  avionic  subsystems  that  connect  to  the  1553A  bus  contain  the  remote  terminal 
within  the  subsystem.  This  approach  simplifies  the  management  of  interfaces,  and  (XTinits 
clear  definition  of  responsibility  for  subsystem  performance.  The  supplier  of  a subsystem  Is 
responsible  for  the  proper  operation  on  the  data  bus  of  that  subsystem. 

In  the  MK-llI  system,  stubs  are  connected  to  the  bus  as  shown  In  figure  9.  This  is  in  lieu  of 
a coupler  box.  The  stub  splices  arc  protected  by  the  backshell  of  the  connector.  Coupling  i.i 

boxes  were  avoided  in  order  to  reduce  weight  and  to  reduce  the  reliability  risk  by  reducing  'I 

the  number  of  connectors. 

h 
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Figure  8 - Lamps  Mk*III  Bus  ControUer/Remote  Terminal  Data  Rates 
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Figure  9 * Lamps  Mk*III  Stub  to  Bus  Connection  Method 


CONCLUSION 


It  U cariy  In  the  LAMPS  MK-III  full  scale  devdopment  phase,  and  therefore  It  Is  difficult  to 
draw  Arm  conclusions.  However,  It  Is  expected  that  several  a^antages  will  accrue  to 
LAMPS  because  of  the  Implementation  ot  a 1553A  data  bus. 

The  system,  the  software,  and  many  of  the  subsystems  and  subsystem  elements  are  all 
simultaneously  In  development.  The  System  prime  contractor  has  been  able  to  simulate  all 
of  the  data  bus  Interfaces,  and  because  of  this.  Is  able  to  develop  and  test  operational  soft- 
ware before  the  actual  equipment  Is  available. 

LAMPS  MK-III  Is  a complex  weapon  system,  and  system  integration  Is  expected  to  be  a 
ms|or  effort.  The  prime  contractor  has  devised  a bus  monitor  which  should  facilitate  the 
analysis  and  localization  of  integration  problems. 

The  reliability  of  data  transmission  within  the  airborne  system  is  expected  to  be  higher 
than  that  demonstrated  In  earlier  developmental  configurations  of  LAMPS  MK-III. 

Rnally,  In  the  later  phases  of  the  system  life  cycle,  replacement  or  addition  of  subsystems 
should  be  far  easier  and  far  less  costly  because  of  the  decision  to  employ  a 1553 A data 
bus  In  the  LAMPS  MK-III. 
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FRENCH  UTILIZATION  OF  Tiff?  DIGITAL  MULTIPLEX  BUS 


Bernard  VANDECASTEELE 


Ministry  of  Defence,  Service  Technique  Aerouautique 

France 


Abstract  ; After  a brief  history  of  the  studies  which  have  been  carried 
out  till  now  in  France  about  data  buses,  this  paper  describes 
the  main  features  of  the  most  used  one.  Then  the  development 
philosophy  followed  by  French  authorities  is  given  and  finally 
the  past  and  current  developments  of  modules,  tools  or  equip- 
ments are  shown. 

Historical  background 

The  first  serial  digital  bus  was  experimented  ia  France  in  1965,  but  the 
very  beginning  of  the  development  of  1 MHZ  digital  multiplex  buses  took 
place  in  1970,  for  use  aboard  strategic  missiles.  Since  1973,  several 
studies  for  airborne  applications  have  been  conducted,  some  of  them  only 
as  experimental  studies,  but  some  others  as  full  development  for  major 
systems.  One  of  the  first  studies  was  GINA  (Gestion  des  Informations 
Numeriques  Aeroportees  or  Airborne  Digital  Informations  Management)  It 
will  be  presented  to  morrow  in  detail  by  M . QUIDET,  This  bus  had  a good 
success  in  France,  since  it  has  be  chosen  for  several  aircraft  : 

Mirage  2000,  the  French  new  fighter  ; Atlantic  Nouvelle  Generation,  a 
new  version  of  an  existing  maritime  patrol  aircraft  ; and  several  versions 
of  the  FI  fighter.  But  it  has  also  been  chosen  by  the  French  Navy.  This  bus 
has  already  become  de  facto  a military  standard. 
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Another  study,  merely  oriented  towards  transport  airplanes,  has  been 
developed  and  flight  tested  : it's  SIGMA  (Systeraed* Interconnexion  Gene- 
ral Multiplexe  pour  Avions,  or  Airborne  Multiplex  General  Interconnection 
System)  which  is  now  involved  in  an  experimental  program  of  avionic 
system's  integration.  The  flight  tests  will  be  conducted  on  a Caravelle 
with  a pretty  name  ; ALIS,  for  Avion  Laboratoire  pour  1' Integration  des 
Systeroes  or  Experimental  Aircraft  for  Systems  Integration. 

Several  other  studies  are  now  being  conducted  upon  power  management 
systems  (E  Mux)  or  for  inter comm  sub  systems. 

Although  these  systems  present  several  differences,  they  all  must  adlier 
to  the  Recoinnendations  of  the  Technical  Integration  Committee  (Comite 
Technique  Integration).  This  committee  is  a working  group  representing 
the  services,  pilots,  manufacturers  and  equipment  users  (Air  Force  Staff 
and  aircraft  companies)  created  to  collect  views  and  experiences  within 
the  field  of  system  integration,  in  order  to  define,  if  possible,  French 
standards  or  to  participate  in  the  formulation  of  international  standards. 
Since  multiplex  data  bus  techniques  are  one  of  the  aids  lo  system  inte- 
gration, they  were  among  the  first  concerns  of  the  Technical  Integration 
Committee.  Their  recommendations,  as  well  as  the  specifications  of  the 
GINA  bus,  have  already  been  published  in  the  AGARD  Advisory  Report  N“  90  : 
A Study  of  Standardization  Methods  for  Digital  Guidance  and  Control  Sys- 
tems. I shall  only  give  you  here  the  main  features  of  the  GINA  bus,. 

For  more  details,  please  refer  to  M , QUIDET'S  paper. 


GINA  main  features 

GINA  is  a 1 M bits/s  digital  multiplex  bus,  the  general  organization  of 
which  is  shown  on  slide  N°  1.  You  can  see  that  each  bus  has  two  lines  : 

LP  (Procedure  line)  and  LD  (Data  Line).  Only  the  MOBs  (Bus  Monitor  a Bus 
Controller)  can  speak  on  the  procedure  line,  to  give  orders  to  the  equip- 
ment. Every  unit  can  hear  and  speak  on  the  data  line.  This  is  done  through 
« COS  (Standard  Coupler)  what  you  call  a Multiplex  Terminal  Interface  Unit. 
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The  second  slide  shows  the  principles  of  the  exchange  procedure.  Each  cha- 
racter has  10  bits  t an  8 bits  byte  for  data  or  conmand,  1 bit  for  validity 
and  1 bit  for  parity.  During  an  exchange,  the  clock  Is  given  on  the  proce- 
dure line  by  the  bus  controller.  So  It  Is  not  necessary  to  have  a clock  in 
every  unit,  and  this  feature  lalnlmlzcs  the  risk  of  uncontrolled  emission 
on  the  bus. 

Slide  N®  3 shows  the  structure  of  the  standard  coupler.  The  connection  Is 
nvadc  through  transformers,  for  coninon  mode  rejection,  to  two  receivers  (one 
on  each  line)  and  one  transmitter  (only  on  the  data  line)* The  transmitter/ 
receivers  part  can  be  duplicated  if  necessary  for  connection  to  a redundant 
bus. 


Devclopnx:»nt  philosophy 

From  the  very  ooglunlng  of  the  development,  and  apart  from  technical  pro- 
blems, a big  question  arose:  wliat  is  to  be  spcclffed?As  the  bus  is  a link 
between  many  equipment,  there  must  be  some  dove lopnx'nt done  by  many  imanu- 
facturers.  In  this  way,  the  question  was  z what  Is  standard,  and  wliat  is 
specific  ? Of  course,  the  minimum  is  to  have  standard  signals  on  tlie  bus, 
l.e.  on  the  wires.  But  we  liave  also  chosen  to  have  a standard  coui>ler,  and 
therefore  standard  signals  and  procedures  between  tlie  standard  coupler  and 
what  we  call  the  sub-system  coupler,  which  Is  the  specific  interlace  hetwt’en 
the  unit  and  the  bus.  In  all  the  programs  which  use  a GINA  bus,  we  have  only 
one  kind  of  standard  coupler,  and  only  one  muuif acturer , at  least  during  the 
development  phase  (We'll  have  other  sources  for  tlie  production  phase).  Till 
now,  this  method  l>as  proven  to  be  efilclcnt,  lor  several  reasons  : 

.-  I'evelopment  time  t It's  much  more  easy  and  last,  lor  an  equlpiiH'nt  nwimi- 
facturcr,  to  design  the  interface  with  a standard  coupler  (TTh  level, 
parallel  signals)  rather  than  with  a bus,  and  all  the  modifications  or 
Improvements  that  could  bo  found  Interesting  on  the  system's  level  can 
be  implemented  In  all  the  equipment  at  a tlnx'. 


- Cost  : we  had  only  one  development  for  this  important  card,  instead 
of  ten  or  twenty  to  do  the  same  Job  ; in  production,  we  will  have  an 
obvious  advantage  of  a larger  quantity  of  the  same  electronic  module 


•-  Technology  homogeneity  : 1 think  that  this  point  is  as  important  as 
the  cost  aspect,  because  a failure  in  a poorly  designed  connection 
module  can  result  in  a failure  of  the  whole  avionic  system. 

So  ve  have  focused  the  studies  on  the  safety  of  the  standard  coupler, 
so  that  in  a system  with  about  20  units  and  a redundant  bus  controller, 
the  safety  of  the  all  transmission  system  is  made  by  that  of  the  two 
controllers,  the  part  of  the  couplers  being  negligible .Moreover,  the 
connection  design  of  all  the  equipment  was  aided  and  tested  with  the 
same  tools,  among  which  you  find  the  Procedure  Generator. 

Past  and  current  developments 

The  following  slides  show  some  modules,  tools  or  equipment  already  deve- 
loped for  the  bus. 

First,  the  standard  coupler,  show  on  slide  N®  A.  Then,  on  the  next  slide, 
a bus  controller  which  had  been  developed  for  the  first  flight  tests  of  the 
bus.  The  most  interesting  thing  can  be  seen  at  the  rear  side  (slide  N®  6)  : 
we  put  a great  emphasis  on  the  technology  of  the  wire  and  of  the  connector. 
The  wire  is  a triply  shielded  pair,  specially  designed  to  have  a high 
immunity,  even  for  the  Electro  Magnetic  Pulse,  and  to  get  the  eviximiin’  of 
this  cable,  we  developed  a connector  which  insures  good  impedance  and 
shielding  continuity. 

The  next  slide  (N®  7)  show  a bus  repeater,  which  nerralts  the  connecti''”  o^ 
a ground  station  on  the  aircraft  bus  at  a distance  of  about  300  feet. 

The  two  next  slides  (N®  8 and  9)  shows  the  rear  side  of  the  bus  repeater, 
witn  the  bus  connector,  and  it's  internal  cards. 
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On  the  next  slide  (N“  10)  you  can  see  the  first  version  of  the  procedure 
generator,  which  is  a development  tool.  Another  version,  controlled  by  a 
micro-processor,  was  also  developed  and  can  be  used  during  the  production 
phase. 

The  last  slide  (N**  11)  represents  an  electronic  bay  which  was  made  and 
used  for  the  preliminary  validation  of  the  bus  concepts. 

Although  there  is  a special  session  about  systems  integration,  I would 
like  to  describe  a few  peculiar  features  of  some  systems  now  being 
developed  in  France. 

In  some  applications,  we  have  chosen  to  have  a non-redundant  bus,  but 

a redundant  bus  management.  This  was  possible  because  of  the  intrinsic 

redundancy  of  the  CTNA  bus,  which  has  two  lines  . As  the  equipment  can 

of 

only  hear  on  the  procedure  line,  you  have  no  risk/ uncontrolled  omission 
on  this  line,  and  a very  little  risk  of  short-circuit,  so  that  you  always 
can  stop,  through  this  line,  a unit  which  disturbs  the  system  through  the 
data  line. 

Another  characteristic  of  some  of  our  systems  is  to  be  synchronous.  For 
this  inirpose,  the  time,  at  a 50  pulses  per  second  rate,  is  distributed  on 
the  bus  to  every  unit.  This  clock  can  be  used  as  an  interrupt,  to  synchro- 
nize the  data  sampling  and  the  program.  I think  Chat,  when  it's  possible, 
a synchronous  system  is  much  more  simple  to  design,  because  all  the  delays 
for  sampling  and  transmission  are  constant  and  well  known.  Moreover,  all 
the  theoretical  support,  as  the  Z transform  lor  example  implicitly  supposes 
that  all  the  operations  arc  synchronous,  whith  exactly  the  same  Ireipiency 
and  known  delays.  Asynchronous  systems  must  be  used  if  there  is  no  other 
possibility,  because  they  are  much  more  demanding,  specially  about  tlu' 
transmission  specifications. 


For  the  future  trendsi  I just  would  like  to  say  that  many  efforts  are 
to  be  done  to  obtain  low  cost  buj  connection*  For  this  purpose,  we  are 
now  developing  large  scale  Integrated  circuits,  which  will  permit  to 
save  space,  and  especially,  to  cut  down  the  costs* 
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By 
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Marquis  W.  Woody 
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Research  & Development  Command 
Warren,  Michigan 


Abstract 


The  Am\y  is  now  developing  multiplex  system  hardware  for  appli- 
cation in  certain  of  its  ground  vehicles.  While  the  complexity  of  the 
electrical  and  electronic  systems  in  such  vehicles  is  considerably  less 
than  that  encountered  in  aircraft,  the  results  of  a study*  reported 
herein  evidences  that  a significant  potential  payoff  can  be  achieved 
through  the  use  of  multiplexing  in  Main  Battle  Tanks  of  the  55  to  60  ton 
class. 

This  paper  summarizes  the  finding's  of  a seven-month  study  funded 
by  the  U.S.  Army  Tank-Automotive  Research  and  Development  Command 
(TARADCOM).  The  study  constituted  the  first  step  in  an  Arn\y  program 
initiated  at  TARADCOM  to  develop  Advanced  Techniques  for  Electrical 
Power  Management,  Control,  and  Distribution  Systems  (ATEPS).  The  ATEPS 
program  was  initiated  in  the  Fall  of  1975.  Subsequent  to  conclusion  of 
the  study  reported  in  this  paper,  TARADCOM  funded  the  development  of 
ATEPS  breadboard  hardware,  which  conforms  to  MIL-STD-1553A,  and  has  just 
recently  been  successfully  demonstrated.  More  recently,  TARADCOM  has 
funded  a study  to  determine  the  applicability  of  the  ATEPS  concept  as 
well  as  the  completed  ATEPS  hardware  to  other  Army  ground  vehicles. 

Summary 

Advanced  electrical  power  management,  control,  and  distribution 
techniques  are  required  to  meet  the  increasing  power  requirement  impacts 
on  combat  vehicles.  Since  World  War  II,  this  power  increase  has  been 
tenfold  with  major  impacts  of  increased  system  complexity  and  reduced 
potential  for  system  reliability.  Vulnerability  and  survivability  of 
wiring  systems  are,  therefore,  receiving  increased  Army  attention. 
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The  initial  ATEPS  study  centered  around  detailed  analysis  of  the 
M60A2  which,  at  the  time  of  the  study,  was  the  best  documented  vehicle 
in  its  class  and  was  sufficiently  complex  to  warrant  its  use  as  a base- 
line vehicle.  Because  conventional  design  techniques  were  employed  in 
the  M60A2,  its  electrical  system  was  found  to  exhibit  the  following 
general  properties: 

- A large  number  of  custom  cables  interconnecting  the  various 
subsystems  and  their  dedicated  controls  and/or  indicators; 

- A large  number  of  dedicated  controls  and  indicators; 

- A computer  dedicated  solely  to  the  fire  control  function; 

- A proliferation  of  relay  logic  to  affect  power  control  functions. 

The  most  significant  end  result  of  the  initial  ATEPS  study  is  the 
conceptual  design  of  an  information  system  for  tanks.  The  information 
system  utilizes  advanced  multiplexing,  data  processing,  and  integrated 
controls  and  display  techniques.  ATEPS  thus  integrates  all  electrical 
and  electronic  functions  in  the  vehicle.  The  study  demonstrates  that 
the  total  Life  Cycle  Cost  (LCC)  of  a Main  Battle  Tank  employing  such  a 
system  promises  to  be  considerably  less  than  that  of  present  vehicles  in 
its  class.  The  information  system  proposed  may  be  regarded  as  a general 
purpose  utility  which  may  be  used  by  any  subsystems  that  require  the 
services  it  is  capable  of  rendering. 

I nf orma t i on_S^s terns  Descr ipt i on 

An  artist's  concept  of  the  information  system  as  it  might  look  when 
installed  in  a tank  is  illustrated  in  Figure  1.  It  consists  of  the 
following  core  elements: 

- An  integrated  power  and  data  bus  (flat  cable) 

- A number  of  compact  Remote  Terminals  (RTs)  which  serve 

as  interface  devices  between  the  bus  and  the  subsystems  it 
serves 

- A Central  Computer  Complex  (CCC)  referred  to  in  the  figure 
as  a dually  redundant  computer 

- Four  identical  Crew  Station  Terminals  (CSTs)  which  perform 
the  integrated  control  and  display  functions. 

It  is  a command/ response  time-division  multiplex  system  under  the 
overall  control  of  a stored-program,  general  purpose  digital  computer. 

Key  elements  of  the  Central  Computer  Complex  are  the  following:  a 16 
bit  Central  Processor  Unit  (CPU)  working  in  conjunction  with  32  thousand 
words  of  semi-conductor  random  access  memory;  a Bus  Monitor  and  Control- 
ler (BMAC)  working  under  the  direct  control  of  the  CPU,  a system  control 
panel,  system  executive  and  applications  software;  a mass  storage  device; 
and  miscellaneous  power  supplies,  inverters,  and  special  purpose  system 
hardware.  The  flat  cable  Multiplex  Data  Bus  distributes  commands,  data, 
and  power  throughout  the  vehicle.  Figure  2 shows  a top  level  block  dia- 
gram of  the  system.  It  provides  the  following  services: 

- Flectrical  power  distribution 

- Computer-aided  electrical  power  management  and  control 
Interconminication  between  subsystems  of  subsystem  sensor  or 
control  data  via  a multiplex  data  bus 


Figure  2 CONCEPTUAL  SYSTEM  BLOCK  DIAGRAM 


- Interconmunicdtion  between  any  crew  member  and  the  outside  world 
via  radio  sets,  etc. 

- Data  processing  (such  as  fire  control  calculations) 

- Control  of  subsystems  via  identical  integrated  multifunction 
manual  input  devices 

- Display  of  measured  or  computed  data  via  identical  integrated 
multi-purpose  display  devices 

- Malfunction  detection  and  reporting 

- Failure  diagnosis 

- Crew  advisory  service  (such  as  display  of  check  lists) 

Its  basic  functions  include  the  following:  encoding  of  manual 
control  inputs  for  selection  and  activation  of  processing  operations, 
display  of  all  information  required  to  operate  the  vehicle,  distribu- 
tion of  all  command,  control,  display,  and  status  information  through- 
out the  vehicle;  automatic  control;  automatic  status  monitoring;  and 
critical  reconfiguration  operations  such  as  controlled  load  shedding  (to 
provide  graceful  degradation).  These  basic  functions  are  augmented  (for 
purposes  of  establishing  the  system  as  a viable  candidate  for  deploy- 
ment) to  include  an  expandable  array  of  data  processing,  monitoring,  at>d 
logging  functions,  additional  peripheral  subsystem  interface  growth 
capability,  and  survivability  features  that  improve  the  useful  product 
life.  Principle  features  of  the  system  are  as  follows; 

- Continues  to  operate  with  no  degradation  of  performance  even 
if  the  power/data  bus  cable  is  severed. 

- Redundant  RTs  can  be  employed  selectively  (but  only  where  ne- 
cessary) to  serve  failure  critical  subsystems  and  provide 
graceful  degradation; 

- Changes  to  the  system  or  subsystem  do  not  necessitate  rewiring 
and/or  overhaul  of  the  vehicle; 

- RTs  may  be  incorporated  inside  the  subsystems,  thus  simplifying 
the  wiring  from  the  bus  to  the  subsystems  it  serves; 

- Stand-alone  RTs  such  as  those  shown  in  the  figure  may  serve 
several  subsystems  in  cases  where  it  is  not  cost-effective 
to  incorporate  RTs  directly  inside  the  subsystems; 

- No  single  failure  in  the  CCC  or  any  of  the  RTs  will  prevent 
the  rest  of  the  system  from  operating; 

- The  system  monitors  its  own  health,  and  automatically  takes 
appropriate  action  should  any  of  its  elements  malfunction; 

- A power  failure  will  not  cause  undesired  output  signals 
from  the  system  to  the  subsystems  it  serves; 

- The  number  of  hul 1 -to-turret  slip  rings  is  reduced  to  14  in- 
cluding two  spares  (the  M60A2  requires  52); 

- Production  connection  of  a subsystem  or  RT  connector  to  the 
bus  is  a simple  crimping  process  which  greatly  reduces  wiring 
cost; 

- The  CCC  and  RTs  are  protected  against  NEMP  (Nuclear  Electro 
Magnetic  Pulse  Phenomena  - the  high  voltage  transients  asso- 
ciated with  nuclear  explosions)  pickup  from  the  multiplex 
data  bus; 

- A novel  interference  cancellation  technique  suppresses  EMI 
pickup  by  the  multiplex  data  bus  signal  lines  from  the 
adjacent  power  lines  in  the  same  cable; 


- Error  detection  and  correction  techniques  permit  system 
operation  In  the  presence  of  any  noise  which  falls  to  be 
rejected  by  the  cancellation  technique; 

- The  system  reduces  the  number  of  Independent  switch  position 
functions  required  by  all  4 members  of  the  M60A2  crew  from 
316  to  80; 

- It  reduces  the  required  number  of  Independent  control  and 
display  equipments  In  the  M60A2  from  12  to  4; 

- It  automatically  calls  the  operator's  attention  to  his  display, 
when  required,  by  means  of  an  audio  cue  signal  transmitted  over 
the  crew  intercommunication  system; 

- It  permits  all  electrical  and  electronic  subsystem  repairs  to 
be  effected  without  the  need  for  depot  overhaul  facilities 
(and  the  resultant  loss  of  vehicle  availability  for  as  much 
as  a full  year); 

- The  power  and  data  bus  will  last  longer  than  the  service  life 
of  the  vehicle; 

- It  can  provide  high-quality  digital  speech  intercommunication 
between  crew  members  or  between  any  crew  member  and  the  radio 
sets; 

- Its  Crew  Station  Terminals  (CSTs)  are  identical  and  inter- 
changeable, thus  reducing  logistical  and  maintenance  costs; 

- The  crew  can  remove  and/or  Interchange  CSTs  In  case  of  battle 
damage  or  CST  malfunctions  due  to  other  causes  (this  is 
effectively  a zero-cost,  immediate-access  spare  capability); 

- Each  crew  member's  display  can  be  displayed  at  any  other  crew 
station  terminal; 

- The  crew  may  easily  replace  malfunctioning  RTs  with  a limited 
number  of  spares  carried  on  board  the  vehicle; 

- The  system  can  replace  relay  logic  with  programmable  computer 
software  logic,  thus  eliminating  a considerable  number  of  re- 
lays as  well  as  the  wiring  between  these  relays; 

- Because  it  is  software  programmable,  system  logic  as  well 
as  system  behavior  in  general  may  be  modified  without  the 
need  for  hardware  changes. 

Figures  3 and  4 illustrate  the  physical  characteristics  of  Remote 
Terminals  and  a Crew  Station  Terminal,  respectively. 

Life  Cycle  Cost  Investigation 

Table  1 summarizes  the  results  of  the  Life  Cycle  Cost  (LCC)  investi- 
gation conducted  in  parallel  with  the  remainder  of  the  study  effort.  It 
shows  the  expected  impact  of  the  system  on  each  major  identifiable  LCC 
element  for  tanks.  The  most  significant  impact  appears  to  be  on  the  op- 
erating and  support  costs  associated  with  depot  overhaul  as  the  ATEPS 
system  will  make  it  possible  to  effect  almost  all  required  repairs  at 
the  lowest  maintenance  level.  Thus,  the  requirement  for  depot  overhaul 
can  be  reduced  in  frequency  if  not  eliminated  altogether. 


TABLE  1 LCC  IMPACT  - LCC  ELEMENTS 
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Prior  to  designing  the  ATEPS  system,  the  requirements  of  an  M60A2 
Main  Battle  Tank  were  rigorously  analyzed.  Its  total  electrical  system 
was  first  broken  down  into  subsystems  as  illustrated  in  Figure  5.  All 
signals  flowing  between  these  subsystems  were  then  listed,  entered  into 
a computer,  and  analyzed,  using  a computer  program  developed  for  the 
Am\y  called  MUXSYS.  Table  2 is  a sample  computer  printout  of  the 
computed  output  results.  The  output  summary  from  MUXSYS  indicates  total 
amount  of  wire  without  multiplexing,  required  bus  data  rate  with  multi- 
plexing, and  the  results  of  sorting  signals  by  type.  MUXSYS  also  com- 
putes the  density  of  signal  sources  and  destinations  to  assist  in  deter- 
mining the  best  locations  for  remote  terminals. 
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Figure  S BAbELlNF  ELECTRICAL  SYSTEM  BREAKDOWN 
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SOFTWARE  APPROACH  TO  MULTICOMPUTER  SYSTEM  ARCHITECTURE 
USING  MIL-STD-1553  DAT ABUS 

1 . INTRODUCTION 

The  assumption  can  be  made,  that  the  design  of  electronic 
systems  for  weapon  systems,  especially  for  flying  weapon 
systems,  will  be  based  on  a standard  data  bus. 

In  comparison  with  point-to-point  connections  this  means 
a fundamental  reduction  of  safety.  Therefore  in  any  case 
a redundant  data  bus  structure  is  necessary.  Not  only 
safety  aspects  require  high  reliability  of  the  data- 
transmission-system.  No  failure  within  an  electronic 
system  should  cause  a break  of  the  entire  mission. 

Therefore,  if  any  of  the  data  bus  components  (controller, 
transmission  line,  RT)  fails,  reconfiguration  has  to  be 
performed  immediately  to  achieve  minimum  system  perform- 
ance reduction.  Reconfiguration  is  not  only  a matter  of 
hardware.  Reconfiguration  should  be  based  on  the  general 
software  concept  of  the  system,  if  optimum  performance 
during  all  mission  phases  is  desired. 

The  same  problems  occur  when  considering  the  computing 
capability  which  is  available.  This  is  the  reason  for 
the  trend  to  distributed  processing.  It  is  therefore 
very  useful  to  see  datatransmission  and  dataprocessing 
as  a closer  problem,  which  should  be  solved  by  means  of 
a proper  software  design. 

(1) 

The  reason  to  emphasize  the  software  approach  is  that  t 

systems  up  to  now  have  been  designed  as  a combination  of  | 

equipment  in  terms  of  hardware.  Thereby  it  has  always 
been  assumed,  that  sometimes  later  somebody  will  take 
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care  of  providing  a software  solution  as  a salvator  for 
all  the  problems.  Exactly  this  attitude  leads  to  all  the 
difficulties  well  known  in  software  development  until  to- 
day. But  this  false  standpoint  has  chances  to  survive  by 
the  phenomenon  of  the  microprocessors.  Many  people  be- 
lieve, that  cheap  chips  allow  the  easy  design  of  systems 
with  distributed  intelligence.  They  don't  see,  that  micro- 
processors of  today  are  representing  the  state  of  the  art 
of  sof twaretechnology  in  the  60ies. 

By  using  microprocessors,  system  development  is  not  made 
easier  and  cheaper,  it  becomes  more  complicated,  more 
difficult  to  understand  and  more  expensive  in  software 
development. 

We  therefore  want  to  show  a way,  which  in  general  leads 
to  a safe  system  development  by  starting  up  from  a safe 
software  design.  Multicomputer,  multi-bus-structures  are 
included. 

GENERAL  METHOD  FOR  SOFTWARE  APPROACH 

Although  applicable  for  all  kinds  of  data-busses,  this 
method  will  be  explained  under  the  assumption,  that 
MIL-STD-1553  bus  will  be  used  in  any  one  of  its  known 
versions. 

Interface  definition 

In  any  case  the  once  selected  bus-structure  is  the  inter- 
face between  the  process,  represented  by  the  peripheral 
equipment,  and  the  software  complex  as  a virtual  machine, 
which  establishes  the  required  computer  capability. 
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The  real  machine,  and  thereby  the  hardware  configuration 
becomes  its  shape  during  solving  the  software  problem. 

2.2  Selection  of  software  tools 

(4) 

For  this  the  selection  of  the  best  software  development 
system  is  necessary,  which  must  be  available  at  the  time 
of  the  anticipated  start  of  program  development.  It  must 
include 


- Real  time  programming  language 

- Translation  system  (i.e.  compiler  or  interpreter) 

- Real  time  operating  system 

- Test  System 

- Special  support  programs 

2.3  Derivation  of  system  functions 

With  respect  to  the  constraints  for  realization  given  by 
tlie  software  system,  the  primary  system  functions  for 
fulfillment  of  the  mission  will  be  derived  according  to 
the  user's  mission  requirements. 

2.4  Data  Structure  analysis 
(5) 

Each  of  those  functions  includes  elements  of  data  pro- 
cessing and  data  transmission,  which  have  to  bo  defined 
before  the  design  of  the  computing  system.  Tliat  design 
is  based  on  the  t ime-quantities-budget  for  data  manipul- 
ation and  tlie  computer  capability  required.  To  elaborate 
tliese  requirements  a very  detailed  study  of  the  data 
structures  of  given  equipments  is  necessary. 
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2.5  (6)  Design  of  the  virtual  machine 

After  all  this  the  virtual  machine  can  be  structured 
according  to  these  data  processing  elements  of  the 
system  functions.  Tlie  criteria  are: 

- contingency  of  the  elements,  i.e.  communication  of 
tasks 

- timing,  i.e.  synchronization  of  tasks 

- complexity,  i.e.  number  and  size  of  tasks 

- reconfigurability  according  to  the  requirements  of  the 
mission  phases,  i.e.  generation  of  independent  data 
processing  modules  as  far  as  possible,  whicli  allow  an 
effective  failure  management,  and  can  be  loaded  dynam- 
ically. 

2.6  (7)  Real  machine  synthesis 

The  structure  derived  for  the  virtual  machine  can  now 
be  transfered  to  the  real  computer  architecture.  Nvimber 
and  arrangement  of  the  computer  elements  (CP-,  Memory-, 
I/O-,  and  communication  units)  follow  imnu'diately . 

The  structure  of  the  virtual  machine  already  implies 
a high  degree  of  modularity,  which  is  exjiressed  by  the 
existence  of  unified  computing  units  in  the  senst'  of  a 
computer  fcimily  within  the  real  macliino.  Tliereby  soft- 
ware compatibility  and  portability  can  be  achieveii. 

Such  computor  design  kit  has  big  additional  advantages  by 
constructive  sl'mj’li.city , economy  and,  by  ttiis,  I'robU'm- 
free  logistics,  because  single  as  we-11- as.  muJjtJ~'^.9'’ii'iiter 
complexes  can  be  arranged  from  only  a few  different 
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elements. 


If  the  requirement  is  accepted,  that  the  task  of  any 
computer  within  the  system  can  be  taken  over  by  any 
other,  identical  computers  is  the  consequence.  Though 
the  bus-controller  of  the  MIL-STD-1553  is  primarily  de- 
fined independently  of  a computer  solution,  and  is  a 
functional  part  of  the  data  transmission  system,  a real- 
ization within  the  computing  complex  can  have  advantages 
with  respect  t'o  failure  behaviour  and  data  exchange  with 
computing  programs. 

2.7  Considerations  on  MIL-STD-1553 

As  already  mentioned,  this  concept  assumes  MIL-STD-1553 
in  any  of  its  variants.  There  are  sometimes  argument- 
ations for  changing  that  standard,  e.g.  improved  inter- 
rupt handling  and  more  flexibility  of  the  transmission 
procedure. 

There  is  no  doubt,  that  a special  modified  MIL-STD-1553 
bus  could  support  a multicomputer  concept  even  better 
than  do  existing  ones.  We  don't  like  to  exceed  a standard 
in  development  if  there  is  no  essential  need.  What  we 
would  like  to  see,  are  extensions  in  the  sense  of  upward- 
compatibility.  Those  are  e.g.  programmable  bus-controller 
and  RT,  allowing  useful  improvements. 

In  aircrafts,  solutions  are  favorized  which  allow  very 
low  couppled  subsystems.  For  safety  reasons  flight  con- 
trol should  be  as  far  independent  from  navigation,  weapon 
delivery,  reconnaissance  etc.,  as  possible. 
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(8)  A so-called  in€er-bus-coupler  is  proposed,  an  RT  with 
passive  connection  to  the  bus-system  of  the  PCS,  which 
receives  basically  all  the  data  transmitted.  Data  which 
are  requested  from  the  other  subsystems  will  be  stored 
in  buffers  and  can  be  accessed  via  normal  RT. 

The  critical  FCS  can  be  connected  to  the  others  either 
in  the  same  way  or  via  a normal  RT  or  bus-controller. 

To  those  meaningful  extensions  of  MIL-STD-1553  we  account 
the  "DISCRETE  BUS"  presented  here  by  VDO. 

In  principle  the  multicomputer  system  derived  before  docs 
not  need  those  extensions. 

3.  DEMONSTRATION  EXAMPLE 

3.1  Combat  Aircraft  Mission 

We  will  now  continue  our  presentation  explaninq  the  gen- 
eral method  of  software  approach  by  an  example. 

How  will  such  a computer  complex  look  like  in  a weapon 
system,  e.g.  in  a compbat  aircraft. 

First  we  present  the  typical  tasks  of  an  avionics  system 
and  its  subsystems  during  the  mission  phases.  The  follow- 
ing phases  are  common  to  combat  aircraft  missions: 

(9) 

- Pre  Flight 

- Take  Off 

- Climb 

- Rendezvous 

- Cruise  (outbound) 

- Search  and  Loiter 
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- Combat 

- Cruise  (homebound) 

- Landing 

- Post  flight 

3.2  Avionics  Subsystems 

(10)  The  subsystems  are: 


Weapon  Delivery  WD 

Navigation  NAV 

Flight  Control  FC 

Communication  COM 

Performance/Monitoring 
and  Chec)t  Out  PM/CO 

Electronic  Counter- 
measures ECM 

Electronic  Counter/ 

Counter  Measures  ECCM 


3.3  Mission/Subsystem  Matrix 

(11)  By  introducing  priority  numbers  a mission  phases/Sub- 
system-Matrix  can  be  established. 

3.4  Software  Approach  and  Design 

3.4.1  Matrix  Analysis 

The  matrix  is  showing  the  6 subsystems  which  are  the 
6 main  tasks  having  changing  priorities.  They  are  run- 
ning under  the  control  of  an  RT-OS  still  to  be  defined, 
which  administrates  inter-task-communication  and  syn- 
chroization.  The  virtual  machine  can  also  still  not  in- 
clude a failure  strategy,  but  first  inputs  are  given  by 
the  priorities. 
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3.4.2  Software  design  requirements 
(12) 

On  the  software  side  a global  address  space  has  to  be 
defined,  which  covers  the  whole  system.  The  programming 
system  to  be  employed  must  allow  the  designer  to  formul- 
ate tasks  without  respect  to  equipment  structure  of  the 
computing  system  by  language  features. 

This  means,  application  of  a higher  level  real  time  pro- 
gramming language  with  features  as  follwos; 

- Description  of  real  time  operation  and  special  distrib- 
ution of  the  computing  system  including 

o Timing  and  syschronization 
o Administration  of  resources 
o File  Management 
o Process  I/O 

o handling  of  process  information  (Bit-handling) 
o Description  of  processor  type, -location,  -address 
range 

o Allocation  of  programs  to  computers 

o Allocation  of  I/O-Equipment  and  data  of  the  technical 
system  to  variables  of  the  problem-oriented  program 
o Description  of  program  communication 

- Fail  Soft  Handling 

- Allocation  of  task  to  computer  depending  on  the  status 
of  the  computing  system 

- Description  of  alternative  ways  for  process  data  acqui- 
sition of  the  computing  system,  the  I/O  system,  tlie 
data  transmission  system  (e.g.  databus)  and  sensors/ 
effectors . 
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These  criteria  are  met  by  the  high  level  RT- language 
PEARL  (Process  and  Experiment  Automation  Real-time 
Language)  already  to  a high  degree.  First  extensions  in- 
cluding description  of  multicomputer  structures  are  now 
developed  and  will  be  available  for  software  develop- 
ment in  a few  years. 

3.5  Real  Machine  synthesis 

If  those  software  tools  are  to  be  applied,  the  real 

machine  can  be  structured  now. 

3.5.1  Description  of  the  elements 

(13)  Considerations  on  cooperation  and  distribution  have 

shown,  that  a complex  of  four  identical  computers  con- 
nected by  bus  systems,  will  be  reasonable. 

The  bus-systems  can  be  divided  into  two  groups; 

- The  computer  complex  internal,  serial  memory-  and 
communications  bus  (S-bus  for  systems  bus) 

- The  computer  complex  external  process  bus  (P-bus) 
according  MIL-STD-1553  "X". 

The  modular  computer  unit  consists  of  the  following 
components ; 

- CPU 

- Local  Program  Memory 

- Communications  Memory 

- Bus  Controller  for  the  access  to  additional 
memories  within  the  multicomputer  system 

- I/O-controller  for  the  access  to  sensors/effectors 
of  the  avionics  system 

- Fault  detection  logic. 
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The  global  memory  attached  to  the  S-bus  is  accessible 
for  each  computer  and  allows  dynamic  reloading,  i.e. 
reconfiguration  of  software  packages. 

3.5.2  Description  of  Functions 

The  function  of  the  computer  complex  is  as  follows: 

In  normal  mode  of  operation  each  computer  has  to  fulfill 
a given  set  of  tasks,  which  is  designed  in  order  to 
achieve  homogenuous  load,  not  too  much  reconfiguration, 
minimum  interdependence  with  other  sets  of  tasks,  and 
total  system  integrity. 

In  case  of  disturbance  or  failure  of  computer  components 
or  their  related  data  transmission  systems,  the  tasks 
will  be  newly  assigned  by  a predetermined  failure  stra- 
tegy. 

The  assignment  follows  the  principle  of  "Dynamic  Hier- 
archy", which  means,  that  under  all  system  states,  each 
computer  can  be  assigned  to  each  task.  One  computer  will 
always  have  system  control,  which  alternates  in  case  of 
a failure  to  another  according  to  the  failure  strategy. 

3.5.3  Description  of  Task  Arrangement  and  Fail  Soft  Strategy 

A possible  task  assignment  during  the  mission  phases 
could  be  performed  as  follows: 

(14)  A complete  decision  table  must  also  cover  fault  inform- 
ation about  any  1553  X bus-components  (controller,  trans- 
mission, RT) . The  table  shows  only  the  most  important 
decision  rules.  Those  concerning  degraded  subsystem  per- 
formance must  be  added. 
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3.5.3  Operating  system  design  aspects 

Reconfiguration  according  fail  soft  strategy  requires 
a specific  organisation  of  the  operating  system; 

- Local  OS  contains  all  functions  for  process  programs 
and  communication.  A stand  alone  operation  must  be 
possible . 

- Global  OS  contains  in  addition  system  start  functions, 
decision  table  and  monitoring  functions. 

(15)  We  leave  these  considerations  now  and  will  present  a few 

(16)  pictures  of  structuring  a virtual  machine  based  on  PEARL 

(17)  as  design  and  programming  language.  We  hope,  these  view- 
graphs  are  self-explanatory  now  for  the  audience. 

4.  CONCLUSIONS 

- Advantages 

o Very  high  probability  of  mission  success 

o Low  effort  for  changing  SW  as  well  caused  by  techno- 
logical retrofit  as  by  system  modification 

o Standard  design  kit  existing  from  few  computing-  and 
data  transmission  components  (i.e.  MIL-STD- 1 553X) 

o Applicable  for  very  different  weapon  systems  because 
of  adaptability  of  the  configurations  to  the  required 
computing  power  (single/-multicomputer) 

o Generalized  system  design  method  to  be  transferred 
to  all  applications;  hereby  low  effort  in  system- 
development  in  further  projects 
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o Very  high  objectivation  of  the  system  by  high  trans- 
parency, therefore  no  more  critically  dependant  on 
persons 

o Projects  today  rated  as  highly  sophisticated,  become 
feasible  by  better  transparency  and  overview. 

Disadvantages 

o Looks  like  additional  HW-Effort 
o Successful  fight  for  a standard  is  necessary 
o System  size  must  not  be  too  small 

o Eventually  difficult  specification  of  the  reconfigur- 
ation or  the  fail  soft  strategy 

o Initially  additional  system  software  development 
necessary. 
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Abstract 

The  multiplex  system,  as  configured  in  the  YAH-64  helicopter,  per- 
forms the  function  of  command  and  control  of  avionic  and  mission  equip- 
ment functions  through  acquisition,  conditioning,  processing,  and 
channeling  of  weapon  system  data  for  over  1,300  signals. 

The  YAH-64  multiplex  system  approach  brings  the  advantages  of  func- 
tional and  configurational  flexibility  to  the  aircraft  while  simultane- 
ously reducing  production  costs  and  increasing  reliability.  In  addition, 
integrated  within  the  YAH-64  multiplex  system  is  the  Fault  Detection/  h 

Location  Subsystem  (FD/LS),  which  provides  the  flight  crew  and  mainten-  i 

ance  personnel  with  aircraft  subsystem  operational  status.  j 

This  paper  discusses  the  design  features,  implementation,  and  1 

operation  of  the  YAH-64  multiplex  system.  Overall  system  operational  I 

features,  redundancy,  and  design  features  will  be  discussed. 

Introduction 

The  YAH-64  Advanced  Attack  Helicopter,  shown  in  Figure  1,  is  being 
developed  for  the  U.S.  Army.  Using  a multiplexing  system  to  transfer  P 

data  and  provide  controls  for  avionic  and  mission  equipments,  the  YAH-64  i 

multiplex  system  makes  extensive  use  of  monolithic  and  hybrid  components, 
including  integrated  automatic  built-in  test  circuitry  and  system  redun- 
dancy. Conforming  to  MIL-STD-1553A,  which  is  the  military  standard  for 


144 


1 


Aircraft  Internal  Time  Division  Multiplex  Data  Bus  Systems,  the  YAH-64 
multiplex  system  makes  this  the  first  helicopter  to  incorporate  an  inte- 
grated avionics/weapons  system  utilizing  a multiplex  data  bus  system  for 
subsystem  interface  and  data  handling. 

Some  of  the  major  functions  performed  through  the  YAH-64  multiplex 
system  include: 

• Mode  control  and  display  data  handling  for  the  rocket,  missile, 
target  acquisition,  pilot  night  vision,  integrated  helmet  sights 
displays,  and  electronic  attitude  indicator  subsystems. 

• Video  selection 

• Provides  flexible  interface  for  avionic  and  mission  equipment 

• Fault  detection  and  location 

! The  present  YAH-64  multiplex  system  contains  a 50  percent  growth 

f capability  in  the  areas  of  memory,  subsystem  interfaces  and  bus  utiliza- 

I tion  time.  Aircraft  weapon  control  and  display  operation  can  be  effec- 

[ tively  modified  through  reprogramming  to  accommodate  system  reconfigura- 

tions foi*  future  requirements  with  minimum  cost  and  schedule  impacts. 

System  Description 

The  YAH-64  multiplex  system  is  a distributed  tir.ie  division  multiplex 
system  consisting  of  13  units,  interfacing  directly  to  the  redundant  data 
busses.  These  13  units  process  more  than  1,300  signal  inputs  and  out- 
puts, scattered  throughout  the  vehicle.  Of  the  13  bus  interfacing  units, 
nine  are  Remote  Terminal  Units  specifically  designed  to  adapt  off-bus 
subsystems  to  the  multiplex  data  bu!^.  Where  possible,  interfaces  to 
Remote  Terminal  Units  have  been  standardized  as  discrete  (bi-level)  ac 
and  dc  analog,  synchro,  and  serial  digital  data.  Functionally,  the 
YAH-64  multiplex  system  replaces  much  of  the  signal/control  wire  and  re- 
lay logic  required  in  conventional  aircraft  configurations.  The  system 
can  be  expanded  to  includ«  32  units  in  order  to  meet  future  requirements. 

Figure  2 is  the  block  diagram  of  the  present  YAH-64  multiplex  sys- 
tem. The  system  consists  of: 

• Dual  data  busses 

• Two  bus  controllers  (primary  residing  in  the  fire  control  com- 
puter; backup  residing  in  the  copilot  compartment  remote  terminal 
unit). 

• Symbol  generator 
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• Missile  system  remote  electronics  unit 

• Electronic  attitude  director  indicator  remote  electronics  unit 


• Four  general-purpose  remote  tenninal  units  located  in  the  pilot's 
compartment,  right  forward  avionics  bay,  left  forward  avionics 
bay,  and  aft  avionics  bay. 

a Four  pylon  remote  terminal  units  (one  located  in  each  pylon). 

• Twenty-six  data  link  termination  units 

Figure  3 illustrates  the  YAH-64  multiplex  system  box  distribution 
throughout  the  aircraft.  The  primary  data  bus  is  routed  on  the  left 
side  of  the  aircraft,  while  the  secondary  data  bus  is  routed  on  the 
right  side.  This  isolation  between  the  busses  increases  survivability. 
Both  bus  controllers  (FCC  and  BBC)  are  widely  separated  for  the  same 
reason.  Critical  signals  can  be  routed  into  separate  remote  terminal 
units  by  providing  separate  signal  paths,  precluding  the  loss  of  that 
function  with  a remote  terminal  malfunction. 

Data  Bus 


The  YAII-64  multiplex  system  data  bus  operates  asychronously  in  a 
command/ response  mode,  with  transmissions  occurring  in  a half-duplex 
manner.  Each  of  the  multiplex  system  data  busses  consist  of  a low  loss 
twisted  shielded,  24  guage,  teflon  insulated  wire  pair,  terminated  at 
each  end  in  its  characteristic  impedance  (71  ohms  nominal).  All  connec- 
tions to  the  data  bus  system  utilize  a small  (.1  lb)  Data  Link  Termina- 
tion Unit  (DLT)  as  illustrated  in  Figure  4.  The  Data  Link  Termination 
Units  provide  the  bus  with  short-circuit  isolation,  impedance  matching, 
and  line  tenuination.  One  DLT  per  bus  is  used  for  each  terminal,  there- 
by requiring  two  DLTs  per  terminal  for  the  dual  redundant  system. 

Information  flow  on  the  data  bus  is  comprised  of  messages  and  words 
per  MIL-STD-1553A.  Data  bus  messages  consist  of  control ler-to-romote 
transfers,  remote-to-control ler  transfers  and,  although  not  presently 
used,  remote -to -remote  transfers.  Data  bus  itviin  frame  time  is  a nominal 
20  milliseconds,  as  shown  in  Figure  5.  During  this  time  period,  the 
active  bus  controller  collects  data  from  all  boxes  on  the  data  bus  (via 
transmit  conunands) , performs  the  t'equired  logic  processing  and  computa- 
tions, and  outputs  the  revised  data  to  all  boxes  on  the  data  bus  (via 
receive  commands).  For  subsystems  that  do  not  require  this  high  update 
rate  (50  times/second),  data  is  processed  and  outputed  at  a lower  rate 
(25  times/ second ) . 
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Bus  Conttyl 

Ourtntj  noniwl  onoration,  sole  contwl  of  inlonnatlon  transmission 
on  the  bus  resides  with  the  active  bus  controller,  which  initiates  all 
transmissions.  The  primary  bus  cont»H>ller  resides  within  the  tire  Con- 
t»x>l  Computer  (FCC)  while  the  Backup  Bus  Cont»x)ller  (BBC)  resides  in  the 
f'oiiote  terminal  unit  located  in  the  copilot’s  compartment. 

The  ICC  is  a general-purpose,  micixH’»'Od»'aii»M»Hi , diviital  parallel, 
synchronous  machine.  The  characteristics  of  the  FCC  aiv  suitinari;ed  in 
Table  1. 


TABLl.  1 

URL  CONTROL  COMi'UllR  GLNLRAl 
CHARACTLRISIICS 


Type 

lleneral  purpose,  miciv- 
pi'ogrammed.  digital 
paral lei , synchivnous 

Meimtry 

16K  \ lb  bits  ROM  { Ibk 
growth) 

.-'k  X lb  bits  RAM 

The  backup  bus  conttv.ler  is  a lu-bit,  C‘H)1A  bit/slice  microptv- 
grammed  processor.  The  characteristics  of  the  backup  bus  controller  are 
suniuari.'ed  in  Table  2, 


TABLl  .: 

BACKUP  BUS  CONIROILLR  C.INIKAL 
CIIARACTlRlsnCS 


Type 

.NO  1 mi  ci'oprogrammed 
processor 

Mtsmn'y 

l.'k  \ lb  bits  ROM 
.'k  X lb  bits  RAM 

Lither  the  primary  or  backup  bus  controller  would  normally  be  tlte 
active  contiMllet',  depending  on  the  states  ot  handsitake  discretes,  a 
selection  switch  in  the  copilot/gunner  cockpit,  and  activity  of  the 
busses.  1 Ih'  block  diagram  of  figure  b shows  the  various  signals  associ- 
ated with  the  selection  of  primai'y  or  backup  bus  controller. 
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Both  controllers  monitor  the  busses  for  activity  In  the  form  of 
valid  commands.  Lights  In  the  Cop Hot/ Gunner  (CPG)  cockpit  Indicate 
whether  primary  or  backup  Is  In  control  and  also  cue  the  CPG  that  the 
backup  controller  has  detected  an  inactive  bus  when  the  primary  was 
supposed  to  be  in  control.  The  logic  for  bus  controller  selection  is 
given  in  Table  3. 


TABLE  3 

BUS  CONTROLLER  SELECTION  MATRIX 


Controller 

1 

CPG 

Switch 

Handshake 

Discretes 

Bus  Activity 

Primary  to 

assume 

control 

Primary 

Backup  not  in 
control 

None  for  120  msec 
(prograiimable) 
or 

at  power  up 

Backup  to 

assume 

control 

Primary 

Primary  not 
in  control 

None  for  120  msec 
(progranmiable) 

Backup 

— 

Don't  care 

In  addition  to  the  normal  bus  control  mode,  the  YAH-64  data  bus 
system  is  capable  of  operating  in  a dynamic  bus  allocation  mode.  The 
backup  bus  controller  was  designed  to  recognize  mode  commands  with  the 
subaddress  field  of  00000.  Subsequently,  four  mode  codes  are  decoded 
with  the  00000  code  resulting  in  a computer  interrupt  in  the  backup  con- 
troller. With  appropriate  computer  prograiwiing  the  "all  zeros"  mode 
coiiriand  is  thus  associated  with  the  dynamic  bus  allocation  function.  The 
three  other  decoded  node  codes  are  assigned  in  the  present  YAH-64  backup 
controller  as  shown  in  Table  4. 


TABLE  4 

MODE  CODE  FUNCTIONS 


Mode  Code 

Function 

00000 

Issues  Computer  Interrupt  in  Backup 
Bus  Controller 

00001 

Clear  Remote  Terminal 

00010 

mil 

Decoded  But  Not  Used 

others 

Not  Decoded 

Multiplex  Remote  Teniiinal  Units 

There  are  four  "standard  aircraft"  multiplex  remote  terminal  unit 
types  used  in  the  YAH-64  data  bus  system. 

These  remote  terminal  units  (identified  as  Types  I,  II,  IIIA,  and 
IIIB)  input  and  output  a standard  assortment  of  bi-levels,  ac  and  dc 
analog,  serial  digital,  and  synchro  input/output  signals  to  all  parts 
of  the  aircraft.  To  fit  the  needs  of  the  YAH-64  aircraft,  these  units 
contain  four  different  input/output  signal  capacities  as  shown  in  Table 
5. 


TABLE  5 


"Standard  Aircraft"  Multiplex  Remote  Terminal 
Unit  Input/Output  Capacities. 


I/O  Type 

Type 

I 

Type 

II 

Type 

IIIA 

Type 

IIIB 

5V  discrete  input 

48 

48 

48 

5V  discrete  output 

56 

8 

56 

56 

28V  discrete  input 

16 

16 

16 

28V  discrete  output 

56 

8 

16 

16 

Switch  closure 

56 

56 

56 

Synchro  input 

1 

Serial  digital  input 

3 

2 

3 

3 

Serial  digital  output 

3 

2 

3 

3 

Doppler 

1 

DC  analog  input 

20 

8 

20 

20 

DC  analog  output 

20 

4 

20 

20 

AC  analog  input 

4 

4 

4 

Precision  AC  analog 
output 

8 

0 

0 

All  "standard  aircraft"  remote  terminal  units  contain  redun- 
dant 1553A  data  bus  interfaces.  When  further  redundancy  is  re- 
quired, such  as  a critical  input  or  output  signal,  that  particu- 
lar signal  is  wired  into  two  separate  remote  terminal  units. 

The  "standard  aircraft"  remote  terminal  unit  contains  suf- 
ficient built-in  test  circuitry  to  detect  95  percent  of  all 
faults  (weighted  by  failure  rate)  within  itself.  At  the  LRU 
level,  these  units  contain  an  internal  test  system  to  check  in- 
put and  output  channels  for  integrity  as  well  as  power  supplies 
and  other  internal  circuitry. 


150 


1 


Figure  7 and  8 show  the  mechanical  outlines  of  the  three  types  of 
MUX  remote  terminals.  All  three  types  of  remote  terminals  have  been 
designed  for: 

• Hard  mounting  without  shock  absorbers 
e Convection  cooling 

• 100  percent  plug-in  modules  (except  power  supply) 

• Hand-mated  connectors 

It  should  be  noted  that  the  Type  II  remote  terminal  shown  mounted 
in  a typical  pylon  requires  an  unusual  box  envelope.  Card  commonality 
between  all  types  of  remote  terminal  units  Is  maintained  in  spite  of 
the  unique  packaging  requirements  for  the  Type  II  remote  terminal  unit. 
The  cards  are  mounted  vertically  In  the  Type  I and  Type  III  remote 
terminals,  and  are  mounted  horizontally  In  the  Type  II  MRTU. 

Electronic  Attitude  Director  Indicator  Electronics  Unit  (EAPI) 


The  EADI  electronics  unit  receives  flight  symbology  information 
via  the  multiplex  data  bus  system  for  display  on  the  pilot's  electronic 
attitude  Indicator.  Placing  this  unit  on  the  data  bus  provides  the 
YAH-64  helicopter  with  a very  flexible  primary  flight  Instrument  since 
symbols  can  be  refotmiatted,  added,  or  deleted  through  software  nxjdifica 
tions.  Symbology  Is  defined  In  the  programiwble  symbol  generator. 

Symbol  Generator 

The  symbol  generator  shown  In  Figure  9 receives  mission  equip- 
ment related  symbology  and  video  switching  infomvition  via  the  data 
bus  for  display  on  either  the  pilot's  or  copilot's  helmet  nwunted 
displays,  or  the  heads  up  or  down  displays  located  in  the  copilot's 
compartment.  In  excess  of  18  syiiibols  can  be  displayed  on  each  of 
these  displays  simultaneously. 


RenK>te  Missile  Electronics 

The  remote  missile  electronics  unit  receives  missile  status  and  out- 
puts missile  command  data  via  the  data  bus. 


Fault  Detectton  Locatton  Subsystem  CFD/LS) 

Integrated  within  the  YAH-64  multiplex  subsystem  is  the  FD/LS. 

The  detection  and  isolation  of  electrical/electronic  LRU  failures  util- 
izes the  multiplex  data  bus  system  and  associated  hardware  for  perform- 
ing the  various  functions.  The  remote  terminals  are  used  for  signal 
conditioning  and  data  transfer.  The  active  bus  controller  is  used  for 
fault  processing,  control,  and  data  storage.  The  multifunction  data 
entry  keyboard  located  in  the  CPG  compartment  is  used  for  FD/LS  command 
initialization,  and  the  TADS  alphanumeric  displays  for  fault  location 
presentations.  The  present  system  fault  detects  and  isolates  over  69 
replaceable  units. 

The  copilot  crew  station  layout  showing  the  locations  of  the  multi- 
function data  entry  keyboard  and  the  TADS  alphanumeric  displays  are 
shown  in  Figure  10.  The  FD/LS  is  capable  of  correctly  identifying  a 
failed  LRU  in  the  air  or  on  the  ground  for  at  least  95  percent  of  the 
failures  monitored,  weighted  by  failure  rates.  In  addition,  the  sys- 
tem false  alarm  rate  does  not  exceed  2 percent. 

The  active  bus  controller  operating  from  data  received  over  the 
multiplex  data  bus,  using  equipment  status  stored  in  memory,  processes 
programmed  algorithms  as  required  to  determine  the  operational  status 
of  the  monitored  LRU.  The  bus  controller  outputs  the  required  infor- 
mation to  the  symbol  generator  which  generates  alphanumeric  messages 
for  display  on  the  TADS  alphanumeric  display. 

When  in  flight,  the  FD/LS  continually  and  automatically  monitors 
the  operational  status  of  the  YAH-64  electronic/electrical  subsystems. 

If  a fault  occurs,  the  aircrew  is  alerted  so  appropriate  action  can  be 
taken.  Major  subsystems  which  are  so  monitored  include  the  missile 
subsystem,  rocket  subsystem,  gun,  automatic  stabilization  equipment, 
pilot  night  vision,  integrated  helmet  mounted  sight  and  display,  dop- 
pler,  target  acquisition  and  designation  system,  symbol  generator, 

EADI,  engine  instruments,  auxiliary  power  unit  and  electrical  sub- 
system. 

Through  special  keyboard  entries,  either  flight  or  maintenance 
personnel  can  command  a particular  subsystem  fault  detection/location 
test  routine.  At  the  completion  of  the  test,  the  results  are  dis- 
played on  the  TADS  alphanumeric  display  for  evaluation.  In  addition, 
in  the  maintenance  mode,  a complete  aircraft  end-to-end  fault 
detection/location  test  can  be  commanded  through  a maintenance  key- 
board entry.  This  test  will  check  all  systems  connected  to  FD/LS, 
and  will  display  all  failed  units  on  the  TADS  alphanumeric  display. 
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I Summary 

i Presently  the  YAH-64  multiplex  system  described  in  this  paper  is 

going  through  the  initial  integration  phase  of  bench  checkout  and  soft- 
ware development.  Bus  interfacing  equipment  including  the  FCC,  BBC, 
RHE,  SG,  and  all  MRTUs  have  been  successfully  integrated  with  both 
primary  and  backup  bus  controllers  in  command.  Non-bus  hardware  inter- 
faces of  the  complete  Hellfire  system  and  IHADSS  have  been  checked  out. 
Software  development  is  about  half  complete  with  approximately  6000 

, words  written  and  integrated.  The  present  schedule  calls  for  a flight 

E test  of  a partial  MUX  system  in  October  1978,  with  bench  testing  of 

the  total  system  to  be  complete  by  January  1979.  First  flight  of  the 
total  MUX  system  is  scheduled  for  April  1979. 

I 

t 
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DEFINITIONS 


BBC 

- 

Backup  Bus  Controller 

EADI 

- 

Electronic  Attitude  Director  Indicator 

FCC 

- 

Fire  Control  Computer 

FO/LS 

- 

Fault  Detection/Location  Subsystem 

HARS 

- 

Heading  and  Attitude  Reference  System 

HMMS 

- 

Hell  fire  Module  Missile 

IHADSS 

- 

Integrated  Helmet  and  Display  Sight  Subsystem 

ORT 

- 

Optical  Relay  Tube 

PNVS 

- 

Pilot  Night  Vision  System 

RHE 

- 

Remote  Hellfire  Electronics 

SG 

- 

Symbol  Generator 

TAOS 

- 

Target  Acquisition  and  Designation  System 
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Figure  1.  Hughes  Helicopters  yAH-64 
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Figure  2.  YAH-64  Multiplex  System  Block  Diagram 
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Figure  3.  YAH-64  Multiplex  System  Unit  Locations 
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Figure  5.  Multiplex  Data  Bus  Frame-Time  Formats 


Figure  10.  Fault  Detection/Location  Subsysteir.  Controls  and  Displays 


EVOLUTION  OF  A MULTIPLEX  SYSTEM 


by 
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Larry  Driscoll 
Howard  Sherman 

Grumman  Aerospace  Corp. 
Bethpage,  N.Y.,  11714 


ABSTRACT 

This  is  a review  of  the  evolution  of  multiplexed 
systems  which  use  distributed  microprocessors.  Two  previous 
papers^ '2  discussed  the  organization  and  application  of 
"SMART  Terminals".  This  paper  covers  actual  systems  applica- 
tions/ hardware  designs  and  their  operational  benefits, 

Grumman  has  been  developing  systems  using  microprocessors 
with  multiplexing  over  the  past  5 years.  We  started  with  an 
8080  design  which  was  used  in  a solid  state  electric  system 
(SOSTEL)  lab  development  system.  This  was  followed  by  a 
design  which  used  3000  microprocessor  chips  in  a 16  bit 
configuration  for  general  purpose  remote  multiplex  terminals, 
again  for  lab  use.  Both  of  these  designs  used  discrete 
circuits  for  the  multiplex  front  end.  Our  next  design  was 
an  eight  bit  version  of  the  3000  series  microprocessor  and 
used  hybrid  receivers  and  transmitters  and  an  LSI  for  the 
Manchester  front  end.  This  design  is  incorporated  into  the 
Pilot's  Control  Panel  delivered  to  Eglin  Air  Force  Base  for 
their  advance  development  store  management  system.  Our 
latest  multiplex  front  end  design  operates  with  our  eight 


1.  Avionics  Multiplexing  with  Smart  Terminals  Oct  75 

2.  Avionics  Multiplexing  with  Smart  Terminals  (An  Update) 
Nov  76 
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bit  3000  microprocessor  or  a discrete  logic  unit  and  vises 
hybrid  transceivers  and  two  LSI's,  one  for  the  Manchester 
front  end  and  the  other  for  1553A  message  control.  This 
design  has  the  dual  bus  interface  on  a 4.25"  by  4.5"  card 
and  is  used  in  our  Integrated  Avionics  Control  Set  (lACS) 
and  the  hydrofoil  engineering  monitoring  and  control  system 
(EMCS)  . 

The  important  aspect  of  this  design  is  not  the  bus 
interface  or  microprocessor  designs.  What  is  important  is 
the  flexibility  provided  to  the  system  designers  and  the 
human  factors  engineers.  In  the  following  paragraphs  we 
will  discuss  the  hardware  and  system  designs  as  we  have  seen 
them  to  date. 


HISTORY 

Decades  ago,  an  airborne  electronic  system  consisted  of 
a few  relatively  simple  pieces  of  equipment  operating  inde- 
pendently. Today,  aircraft  rely  on  a greater  number  of 
sophisticated  multi-purpose  interdependent  black  boxes  for 
protection  end  completion  of  their  missions.  The  main 
challenge  to  the  avionics  industry  for  decades  has  been  the 
shift  to  greater  reliance  on  electronics  to  perform  in  an 
environment  which  restricts  size,  weight  and  power  consump- 
tion. The  undertaking  has  been  made  oven  more  difficult  by 
the  need  to  add  more  functions  and  capabilities  into  airborne 
platforms  as  the  technology  advances.  Microminiaturization 
has  helped  decrease  equipment  size,  weight  and  power  consump- 
tion greatly.  It  has  also  helped  solve  the  demand  to  add 
more  electronic  capability.  However,  the  added  capability 
has  increased  the  difficulty  of  integrating  the  system  com- 
ponents by  establishing  additional  interfaces.  The  addition 
of  more  equipments  has  caused  a reduction  in  cockpit  space 
and  an  increase  in  pilot  workload  required  to  exercise  them. 
The  operational  impact  has  become  so  severe  that  pilots  £,re 
now  describing  their  tasks  as  - overloaded,  overburdened, 
error  producing  environment,  etc.  So,  emphasis  has  shifted 
to  generating  systems  that  produce  a reduced  amount  of  more 
meaningful  information  for  the  crew  while  integrating  hard- 
ware functions  to  save  equipment  space  in  the  cockpit.  The 
multiplex  approach  satisfies  this  reed  completely.  Multi- 
plexing techniques,  along  with  microprocessor  controlled 
remote  terminals,  allows  centralized  cockpit  control  of 
several  subsystems  through  a single  keyboard  and  display. 

The  basic  electronics  associated  with  these  subsystems  can 
be  remoted  in  available  non-critical  space  in  the  vehicle. 
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In  addition,  we  can  significantly  relieve  the  pilot  workload 
by  performing  for  him  the  mental  integrations  he  formerly 
required  in  using  stand-alone  equipments.  Helicopter  pilots 
for  example,  currently  required  to  mentally  integrate  torque, 
outside  air  temperature  and  engine  RPM  can  now  receive  a 
direct  readout  of  percent  power  - the  information  he  really 
needs . 

MUX  implementation  also  allows  us  to  make  redundant 
functions  immediately  available  with  a lot  less  hardware 
than  required  by  stand-alone  equipments.  And  - we  can  get  a 
switchover  which  is  performed  smoothly  and  automatically  so 
that  the  crew  can  continue  to  operate  without  a break  in 
continuity.  At  some  reasonable  break-point,  we  inform  the 
crew  they  are  on  a back-up  system. 


OPERATIONAL  CONSIDERATIONS 

Advantages  gained  from  using  a centralized  cockpit 
system  are  obvious.  There  are,  however,  pitfalls  to  be 
avoided  if  the  implementation  is  to  be  successful.  Most  of 
these  pitfalls  are  eliminated  through  good  human  factors  de- 
sign. The  systems  we  are  addressing  are  being  produced  for 
use  by  a human  operator.  It  is  therefore  mandatory  to 
insure  that  the  operator  can  easily  perform  his  tasks  with 
these  equipments.  If  he  cannot'  - he'll  make  mistakes.  And 
when  he  makes  errors,  he  will  soon  stop  using  the  equipment 
even  if  he  has  to  break  it  to  make  that  possible.  During 
our  Integrated  Avionics  Control  Set  (lACS)  program,  we 
frequently  evaluated  the  amount  and  quality  of  information 
provided  to  the  operator.  lACS  equipment  centralizes  control 
in  the  cockpit  for  a number  of  navigation  and  communication 
equipments.  Although  the  configuration  of  the  I ACS  system 
permitted  display  of  a large  amount  of  information  to  the 
crew,  an  analysis  established  the  final  information  lequire- 
ment.  This  information  was  limited  to  only  the  minimum 
required  for  the  crew  to  perform  the  task.  Too  much  infor- 
mation can  be  confusing  and  will  be  unavailable  in  a quick 
scan. 


The  lACS  primary  display  equipment  is  shown  in  Figure 
1.  The  display  on  the  Primary  Control  Panel  is  limited  to 
five  rows  of  eight  characters.  This  display  has  proved  more 
than  adequate  for  presenting  lACS  information  and  was  readily 
useable  for  incorporating  doppler  information  as  well.  The 
doppler  was  a growth  feature.  The  display  is  red  incandescent 
to  meet  a program  requirement  for  visibility  in  high  ambient 
light.  The  incandescent  light  is  piped  through  fiber  optics 
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to  form  segment  readouts  - which  are  encased  in  a stycast 
block.  The  face  cannot  be  dirted,  smudged  or  broken  to 
cause  display  degradation  as  is  the  case  with  glass  faces 
and  filters. 

Another  major  design  concern  is  the  keyboard  switch 
pushbutton  force.  These  new  systems  require  extensive  in- 
teraction between  the  operator  and  the  equipments  through  a 
keyboard.  This  is  a new  task  for  a flight  crewman  and  he 
approaches  it  with  skepticism.  Unlike  the  average  portable 
computer  keyboard,  establishing  forces  for  a keyboard  on 
flight  vehicles  assumes  a role  of  major  importance.  The 
operator  wears  flight  gloves  aboard  our  military  flight 
vehicles.  The  flight  vehicle  is  rarely  as  stable  as  the 
desk  top.  On  the  lACS  progreun  we  found  the  bubble  switch  to 
be  inadequate  for  our  purposes  and  have  gone  to  a miniature 
switch  of  leaf  design.  During  our  testing  it  became  obvious 
that  you  could  meet  force  requirements  but  not  provide 
reasonable  feedback  to  a point  where  the  operator  found  the 
whole  system  unacceptable.  With  this  switch  we  are  able  to 
obtain  our  desired  forces  while  maintaining  a positive  feed- 
back to  the  operator. 

One  other  error  contribution  should  be  emphasized. 

When  controlling  a large  number  of  equipments  via  software, 
it  is  mandatory  to  establish  the  operating  philosophy  early. 
This  philosophy  must  be  consistent  with  the  past  experience 
of  the  crewman.  If  the  requirements  for  operating  are 
inconsistent  with  the  operator's  past  experiences  on  those 
or  similar  equipments,  we  have  built  in  an  error  producing 
situation.  You  cannot,  for  exaunple,  make  the  operator  "turn 
pages"  from  top  to  bottom  if  he  is  used  to  turning  from 
bottom  to  top.  Operations  should  be  minimized  wherever 
possible.  Our  lACS  system  utilizes  essentially  the  seune 
operating  philosophy  for  its  centralized  control  of  remoted 
equipments  as  the  individual  equipments  had  originally.  In 
simulations  of  military  missions  our  operators  made  no 
mistakes  with  the  equipment  after  only  an  hour  of  training. 


REDUNDANCY 

Multiplexing  provides  a means  of  transferring  data  and 
commands  from  multiple  units  over  the  seune  transmission 
line(s).  Multiple  sources  and  destinations  for  the  data  and 
commands  are  accommodated  within  the  system  architecture. 
When  the  associated  subsystem  units  utilize  microprocessors 
the  degree  of  system  backup  or  number  of  modes  for  degraded 
operation  is  limited  technically  only  by  the  penalty  of 


additional  firmware,  size,  weight,  and  power.  In  addition, 
the  procurement  costs,  both  developmental  and  per  unit  price 
must  be  considered. 

Determination  of  system  redundancy  can  be  accomplished 
by  assigning  a priority  to  each  system  function  and  providing 
back-up  operation  based  on  the  subsystems  (or  multiplex 
units) , potential  failure  rate,  impact  on  crew  workload,  etc. 
as  related  to  the  mission  requirements.  An  example  of  this 
would  be  two  interactive  control  panels;  one  assigned  to 
stores  management;  the  other  to  Comm/Nav  control.  Both 
panels  could  perform  both  functions  if  required  and  provide 
redundancy  with  only  the  addition  of  firmware.  Using  this 
approach,  a single  keyboard  can  be  used  for  all  subsystem 
data  entry  requirements  as  long  as  there  is  a means  of 
indicating  the  subsystem  being  addressed.  A second  keyboard 
then  provides  full  redundancy  for  all  system  keyboard 
requirements . 


GROWTH  AND  FLEXIBILITY 

The  1553A  multiplex  standard  provides  for  two  basic 
control  modes,  command/response  and  dynamic  bus  allocation. 

In  the  basic  command  response  operation  remote  terminals 
receive  and  transmit  data  only  when  commanded  to  do  so  by  the 
bus  controller.  The  bus  controller  would  tend  to  be  a central 
processor  which  would  then  function  to  control  the  flow  of 
data  among  all  system  elements.  In  addition,  a back  up 
controller  is  required  which  is  capable  of  recognizing  faulty 
primary  bus  control  operation  and  taking  over  the  system 
control  function.  The  ability  of  the  bus  controller  to 
minimize  data  bus  traffic  when  operating  in  conjunction  with 
"intelligent"  subsystems  becomes  a significant  controller 
design  criteria.  Should  an  associated  subsystem  perform 
local  processing  functions  and  transmit  data  only  on  an  "as 
required"  basis  this  additional  task  must  now  be  resident  in 
the  bus  controller  for  total  system  compatability . Under  the 
command/response  multiplex  control,  any  changes  in  associated 
subsystems  will  require  a change  in  the  primary  and  secondary 
controller  software  (firmware) . 

In  dynamic  bus  allocation  designated  terminals  within 
the  system  are  offered  control  of  the  data  bus.  This 
approach  provides  a powerful  tool  for  a system  in  which 
growth  and  changes  can  be  accommodated  with  a minimal  impact. 
As  subsystem  changes  occur  the  impact  is  limited  to  the 
particular  unit  or  units  associated  with  the  change.  In 
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addition,  the  design  criteria  and  requirements  for  the  bus 
controller  become  minimal  since  the  primary  function  is 
periodically  to  transfer  bus  control  from  one  subsystem  to 
another.  The  back-up  controller  must  still  be  capable  of 
recognizing  faulty  primary  bus  control  operation  and  taking 
over  the  system  control  functions. 


SYSTEM  APPLICATIONS 

The  Integrated  Avionics  Control  Set  (lACS)  AN/ASQ-166  is 
an  integrated  Comm/Nav  control  system.  This  is  an  appli- 
cation where  the  benefits  are  primarily  operational.  Valuable 
cockpit  panel  space  is  opened  up,  redundant  control  capability 
is  provided,  centralized  controls  reduce  work  load  and 
redundancy  permits  graceful  degradation  in  case  of  failures. 

The  block  diagram  in  Figure  2 shows  one  possible  system 
configuration.  All  five  units  use  the  BIU  card  (Figure  ?) 
and  two  units  incorporate  the  microprocessor  module  (Figure 
4) . The  primary  control  unit  also  contains  an  eraseable  NDRO 
memory  card  which  stores  all  presets  and  last  operating 
modes. 


Two  microprocessors  are  used  in  lACS  to  provide  redun- 
dancy for  bus  control  and  system  operation.  When  the  lACS 
operates  on  a stand-alone  basis  any  unit  can  fail  and  some 
Comm/Nav  capability  will  still  be  available.  In  fully  inte- 
grated 1553A  systems,  lACS  operates  as  a subsystem  utilizing 
dyneunic  bus  control.  This  approach  minimizes  the  impact  on 
the  system  bus  controller  software.  lACS  could  also  operate 
in  a fully  remote  configuration  using  terminal  to  terminal 
transfers.  This  approach  jilaces  the  burden  on  the  system  bus 
controller  to  initiate  all  data  transfers,  which  results  in 
an  increase  in  bus  overhead  and  controller  software  com- 
plexity. 

Operationally,  the  two  microprocessors  guarantee  that  as 
long  as  one  control  panel  is  operational  full  system  control 
is  available.  The  system  loses  control  capability  only  when 
a control  unit  is  lost.  Then  only  the  units  interlaced  by 
that  control  unit  are  lost.  It  can  be  seen  that  as  more 
equipment  is  interfaced  directly  to  the  bus  as  the  ARN-128 
is,  the  greater  the  benefits  of  a multiplexed  system. 

The  Primary  Control  Indicator  (PCI)  provides  full 
system  control  via  dedicated  switches  and  interactive  dis- 
play/switch function.  All  data  shown  on  the  fiber  optic 
alpha-numeric  displays  is  under  control  of  the  microprocessors. 
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The  switches  on  the  panel  are  also  read  by  the  microprocessors 
and  are  interpretted  based  on  what  is  on  the  display.  This 
approach  permits  modification  and  addition  of  control  func- 
tions with  only  a firmware  change.  Growth  of  this  type  is 
provided  for  in  the  present  hardware. 

The  Secondary  Control  Indicator  operates  using  either 
microprocessor  for  controlling  the  single  line  display  and 
interpretting  the  control  switches.  Since  the  same  firmware 
is  used  for  both  primary  and  secondary  panels  the  control 
capability  is  the  same.  The  only  limitation  is  operational 
due  to  the  limited  display  on  the  secondary  control. 

The  Status  indicator  is  a repeater  which  will  display 
whatever  is  sent  to  it  via  the  1553A  bus.  In  lACS  this  unit 
is  used  to  indicate  channel,  frequency,  and  secure  status  of 
the  selected  transmitter. 

The  control  units  provide  the  function  of  making  todays 
Con\m/Nav  equipment  compatible  with  a 1553A  system.  As  new 
avionics  are  developed  with  I553A  interfaces,  units  such  as 
these  should  gradually  disappear. 

Thanks  to  multiplexing  and  microprocessors,  the  lACS 
units  can  be  used  in  different  combinations  to  meet  a system 
requirement.  In  the  past  we  would  have  had  to  change  the 
system  around  to  accommodate  the  hardware.  By  assigning  the 
terminal  addresses  we  can  design  a system  with  two  primary 
control  indicators,  two  status  indicators,  a secondary  con- 
trol indicator  or  any  other  combination  of  units.  With  a 
software  change  the  control  function  could  be  a store  manage- 
ment system,  a solid  state  electric  system,  or  even  an  engine 
monitor  and  control  system. 


HYDROFOIL  ENGINE  MONITOR  AND  CONTROL  SYSTEM  (EMCS) 

In  this  application  we  are  using  the  same  building  block 
as  in  lACS  to  provide  an  EMCS  (Figure  5)  which  is  fault 
tolerant  and  not  burdened  by  the  penalties  of  a fully  redun- 
dant hardwired  system. 

The  EMCS  is  made  up  of  six  "intelligent"  multiplex  ter- 
minals each  capable  of  monitoring  and  evaluating  input  signals 
representing  subsystem  operational  parameters.  These  six 
terminals  provide  ail  of  the  control  and  monitoring  functions 
required  to  operate  the  basic  hydrofoil  boat  control  subsystems. 
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Control  and  display  functions  operate  the  same  as  lACS 
using  interactive  alphanumeric  displays  with  multifunction 
pushbutton  switches  on  each  side.  The  engineering  operating 
station  (EOS)  has  two  sets  of  interactive  displays;  one 
general  purpose  and  one  dedicated.  The  general  purpose 
display  provides  for  selection  of  all  parameters  monitored 
by  the  system  including  those  on  the  dedicated  displays. 

The  multifunction  switches  on  each  side  permit  control  of 
any  function  which  is  programmed  onto  the  display.  A dedi- 
cated control/display  is  used  to  present  system  parameters 
which  are  considered  as  critical  and  should  be  displayed  at 
all  times.  Either  display  can  be  used  as  a backup  for  the 
other  display  in  case  of  a failure. 

With  each  control/display  being  driven  off  of  different 
terminals  a single  failure  cannot  wipe  out  all  control/display 
capability.  This  partitioning  of  functions  to  limit  the 
amount  of  system  degradation  due  to  a failure  is  also  incor- 
porated into  the  selection  of  monitor  and  control  parameters 
for  each  terminal.  Any  control  or  parameter  considered  to 
be  critical  is  routed  through  two  or  more  terminals.  This 

provides  a level  of  redundancy  which  would  be  very  costly  ^ 

to  accomplish  with  a hard  wired  system.  Since  each  terminal  ij 

handles  its  own  processing  a true  partitioning  of  the  system  U 

software  is  accomplished.  This  also  reduces  the  traffic  on 

the  bus  for  now  only  processed  data  required  for  display  or  ^ 

control  is  on  the  bus  while  data  evaluation  is  performed  at  1 

the  terminal.  The  processor  in  each  terminal  also  provides 

benefits  where  multiple  failures  have  occurred.  The  terminals  i 

can  be  programmed  to  output  a predefined  set  of  control  func- 
tions or  a control  function  based  on  data  being  monitored 

within  the  terminal.  In  this  way  if  both  bus  controllers  are  j 

lost  and  there  is  no  other  terminal  programmed  as  a backup 
controller,  a safe  control  situation  can  still  be  maintained. 


HARDWARE 

We  have  developed  a group  of  building  blocks  for  use 
in  designing  multiplex  systems.  Some  of  these  are  the  bus 
interface  unit  (BIU) , microprocessor  module,  control  card  for 
"dumb"  terminals,  standard  I/O  cards,  and  high  efficiency 
(75%)  power  supply  modules.  The  BIU  and  the  microprocessor 
module  are  described  in  the  following  paragraphs. 

Bus  Interface  Unit  (BIU)  - Figure  3 is  a picture  of  the  BIU 
card  which  provides  a dual  1553A  bus  interface.  The  block 
diagram  in  Figure  6 shows  the  functions  incorporated  in  the 
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BIU.  The  transceivers  are  hybrids,  the  encoder/decoder  and 
buffer  are  forty  pin  LSI's,  and  discrete  circuits  are  used 
for  watchdog  timer  and  bus  switching.  Most  of  this  is  very 
similar  to  other  designs  presently  in  vise  with  the  exception 
of  the  buffer  LSI.  This  device  is  designed  to  provide  all 
basic  1553A  message  control  while  providing  a simple  inter- 
face to  either  a microprocessor  cr  fixed  logic  terminal 
design. 

The  buffer's  primary  function  is  to  provide  the  serial 
to/from  parallel  conversions,  the  controls,  interrupts,  and 
status  information  for  the  user.  It  is  designed  as  a 40  pin 
LSI  device  and  maintains  the  independent  transmit/receive 
paths  of  the  encoder/decoder.  Data  transfer  functions  are 
provided  by  a 16  bit  transmit  and  a 16  bit  receive  buffer 
storage.  These  are  organized  in  8 bit  bytes  to  accept  or 
deliver  data  to  the  8 bit  tri-state  bus  in  response  to  take 
and  read  signals  from  the  user.  Interrupts  and  controls  are 
generated  in  response  to  command  word  reception  of  the  com- 
mand type  (transmit,  receive,  broadcast) . Mode  controls 
provide  the  flexibility  to  initialize  the  unit,  initiate  or 
respond  with  transmissions,  and  provide  the  flexibility  for 
the  unit  to  operate  as  either  a remote  terminal  responding  to 
commands  or  as  a bus  controller  initiating  commands.  Status 
information  is  provided  as  tri-state  (or  discretes)  outputs 
which  alert  the  user  of  unique  polling  offer  word  fields, 
data  transfer  alerts,  and  critical  operating  conditions  or 
modes.  The  unit  has  several  unique  and  automatic  functions 
such  as  a message  complete  function.  This  operates  to  alert 
the  user  of  the  thirty-third  v,-ord  transmitted  in  the  case  of 
a bus  controller.  In  addition,  as  a remote  unit,  it  is  gen- 
erated in  response  to  the  correct  number  cf  data  words  received 
or  the  correct  number  of  words  transmitted  and  initiates 
and/or  stops  transmission.  Internal  idle  line  resets  cause 
the  unit  to  revert  to  the  receive  mode  in  the  event  of  message 
failures. 

Microprocessor  - The  most  important  part  of  a flexible  design 
is  the  microprocessor  and  its  marriage  to  the  BIU.  Figures  4 
and  7 are  a picture  and  block  diagram  respectively  of  an 
eight  bit  microprogrammed  microprocessor.  The  CPE's  and 
look-ahead  carry  on  one  card,  and  the  interrupt  control, 
micro  control,  512  word  micro-memory,  and  pipe-line  on  a 
second  card  which  plugs  into  the  CPE  card.  The  microprocessor 
instruction  set  has  been  designed  specifically  for  multiplex 
terminal  applications.  There  are  special  instructions  for 
bus  control,  bus  interface  and  input/output  data  handling. 

Eight  priority  interrupts  are  provided  with  the  two  highest 
reserved  for  the  transmit  and  receive  interrupts  from  the  BIU 
buffer. 
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The  processor  design  provides  for  addressing  up  to  G4k 
words  of  memory  using  a memory  extension  register  under  con- 
trol of  a micro  bit. 


CONCLUSION 

Multiplex  technology  bridges  the  gap  between  hardware 
and  system  development.  We  can  nov;  satisfy  operational 
requirements  in  a realizable  and  controllable  manner  which 
allows  the  use  of  current  and  near  future  avionics  hardware. 
Our  experience  with  the  systems  presented  has  confirmed  that 
the  basic  building  block  cf  multiplex  technology  will  be  the 
cornerstone  of  future  systems. 
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FIGURE  1.  lACS  PRIMARY  CONTROL  INDICATOR 
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FIGURE  2.  lACS  SYSTEM 
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FIGURE  5.  ENGINEERING  MONITORING  & CONTROL  SYSTEM  (EMCS) 
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ABSTRACT 

Current  approaches  to  aircraft  design  have  identified 
stores  management  as  a distant  function  entity.  In  general, 
aircraft  stores  are  defined  as  the  complement  of  weapons 
and  suspension  devices  which  are  intended  as  line  replace- 
able. The  management  of  aircraft  stores  involves  the  control 
and  communications  system  necessary  in  providing  the  pilot 
efficient  interaction  with  the  aircraft  stores  which  are 
present. 

Recent  technology  advances  have  provided  the  impetus  to 
optimize  the  design  and  integration  of  Stores  Management  Sys- 
tems (SMS)  with  two  principal  goals  in  mind:  (1)  reducing 
the  complexity  of  the  hardware  required  without  sacrificing 
the  capability  and  reliability-  of  stores  management  features; 
and  (2)  increasing  the  range  of  applications  of  stores  man- 
agement systems  in  order  to  reduce  the  number  of  custom  air- 
craft/stores configurations. 

This  paper  discusses  alternative  stores  management  con- 
figurations and  proposes  a modular  data  system  architecture 
utilizing  a nested  arrangement  of  MIL-STD-1553B  multiplex  data 
bus  links.  The  rationale  for  the  selection  is  based  on  the 
opportunity  for  future  SMS  configurations  to  capitalize  on 
current  and  anticipated  breakthroughs  in  related  technologies . 
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I. 


INTRODUCTION 


This  paper  will  document  the  results  of  a research  effort 
sponsored  by  the  Air  Force  Office  of  Scientific  Research  and 
performed  in  support  of  the  Armament  Laboratory  at  Eglin  Air 
Force  Base.  The  research  has  specifically  involved  problems 
related  to  aircraft  Stores  Management  Systems  (SMS)  and  asso- 
ciated technologies, 

• centralization  of  stores  management  functions, 

• functional  partitioning  of  stores  management  functions, 
and 

• transparency  of  pilot-to-store  and  store-to-pilot  in- 
terface; 

as  well  as  system  concepts  such  as: 

enhancement  of  reliability  and  confidence  levels, 

• aircraft/stores  interoperability,  and 

• minimization  of  pilot  recognition/reaction  time. 

Perhaps  the  pre-eminent  issue  involving  aircraft/stores 
interface  is  one  of  rising  life-cycle  costs  associated  with 
growing  set  of  aircraft  and  stores  having  limited  interopera- 
bility characteristics.  This  situation  has  evolved  primarily 
because  interface  standards  have  been  nonexistent  and  stores 
have  traditionally  been  designed  for  specific  aircraft/ 
applications . 

A solution  to  the  interoperability  problem  will  involve 
a well-conceived  set  of  standards  and  some  radical  departures 
from  established  design  strategies  for  Stores  Management  Sys- 
tems. In  addition,  a careful  assessment  of  technology  trends 
must  be  undertaken  to  pinpoint  those  technologies  which  should 
be  further  encouraged  by  the  Air  Force,  and  where  technology 
breakthroughs  should  be  anticipated.  An  SMS  to  address  the 
needs  of  aircraft  for  the  1980's,  1990's,  and  beyond  will 
need  to  be  flexible  as  well  as  efficient  (goals  which  are 
usually  incompatible)  and  must  take  advantage  of  the  most 
current  systems  and  hardware  technology. 

II.  BACKGROUND  AND  RATIONALE 

An  aircraft  Stores  Management  System  must  provide  a 
suitable  interface  between  the  pilot  and  the  full  complement 
of  aircraft  stores  and  associated  suspension  equipment  which 
is  onboard.  This  interface  must  be  capable  of  providing  the 
pilot  with  the  communications,  control,  and  display  functions 
necessary  for  efficient  management  of  onboard  stores  during 
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all  phases  of  a particular  mission.  Figure  1 illustrates  the 
conceptual  problem  associated  with  providing  this  interface. 


Figure  1.  Virtual  and  Actual  Pilot-Stores  Interface. 

The  solid  connecting  lines  indicate  the  hardware  interfaces 
which  are  present  and  necessary  for  the  integration  of  pilot/ 
aircraft/stores  functions  and  operations.  The  dashed  connec- 
tor shows  a "virtual"  interface  which  reflects  direct  pilot 
interaction  with  onboard  stores.  An  efficient  Stores  Manage- 
ment System  will  provide  the  appearance  of  virtually  direct 
control  but  will  utilize  all  appropriate  aircraft  subsystems 
and  interfaces  in  performing  the  Stores  Management  functions. 

If  one  begins  with  the  attributes  which  are  characteris- 
tics of  an  over-all  Stores  Management  System,  the  following 
list  includes  the  principal  items  which  must  be  addressed: 

• effective  centralization  of  the  functions  associated 
with  stores  management; 

• continuous  pilot  appraisal  of  the  complete  inventory 
of  stores  onboard; 

• a flexible  but  efficient  means  for  control  of  any  of 
the  available  stores'  operational  modes; 

• maximum  interoperability  of  available  aircraft  and 
stores ; 

• transparency  of  pilot-to-store  and  store-to-pilot  in- 
terface ; 

• minimum  pilot  recognition/reaction  time; 

• enhancement  of  system  reliability  and  confidence  levels. 

To  a fairly  high  degree,  the  attributes  listed  above  are 
achievable  with  the  exception  of  the  fourth  item — interopera- 
bility of  aircraft  and  stores.  Unfortunately,  it  is  the  in- 
teroperability attribute  which  has  the  most  drastic  effect  on 
the  operational  costs  of  an  aircraft/stores  suite.  These  op- 
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erational  costs  can  be  considered  to  include  penalties  which 
are  not  strictly  dollar  costs,  such  as:  a limited  set  of  air- 
craft on  which  stores  can  be  flown;  the  time  associated  with 
flight-time  operations  in  fitting  aircraft/stores  configura- 
tions; and  logistics  and  repair  delays  associated  with  custom 
aircraft/stores  configurations. 


Despite  the  difficulties  inherent  in  the  development  of 
a Stores  Management  System  which  will  have  application  across 
a wide  range  of  aircraft  and  stores,  progress  in  related  areas 
in  making  this  objective  feasible.  There  are  two  specific 
design  trends  which  are  influencing  the  evolution  of  Stores 
Management  Systems: 

(1)  Increased  use  of  digital  techniques  and  microelec- 
tronics devices.  This  trend  places  added  emphasis 
on  distribution  of  signal  and  data  processing,  digi- 
tal multiplex  data  bus  communication,  and  highly 
modular  hardware  systems. 

(2)  The  use  of  increasingly  information-intensive  system. 
This  results  in  the  realization  of  a greater  propor- 
tion of  functions  via  software  and  closer  attention 
to  the  application  of  engineering  principles  to  all 
aspects  of  the  software  life  cycle. 


There  are  a number  of  current  digital  multiplex  commun- 
ications/processing systems  in  various  stages  of  development 
which  reflect  the  trends  outlined  above.  A representative 
list  includes: 

•F-15  Avionics  Data  Bus  1 — operational 
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•F-16  Stores  Management  Set 
•F-18  Redundant  Multiplex  Data  Bus 
•B-1  Data  Multiplex  Buses 

• Space  Shuttle  Multiplex  Data  Bus  System 

• Navy  Shipboard  Data  Multiplex  System  (SDMS) 


I — Developmental 


•Eglin  F-4E  SMS  Flight  Test  Program 
•AFAL  DAIS  Multiplex  System 
"Integrcited  Digital  Avionics  for  Medium 
STOL  Aircraft  (IDAMST) 

•Advanced  Remotely  Piloted  Vehicle  (ARPV) 


Investigative 


This  list  represents  a group  of  bellwether  systems  from 
which  valuable  lessons  can  be  learned  regarding  systems  design 
for  advanced  military  aircraft.  By  no  means  is  this  group  in- 
clusive of  all  systems  which  offer  data  points  useful  in  deter- 
mining directions  for  evolving  Stores  Management  Systems.  Other 
sources  include  industrial  systems,  telecommunications  systems, 
programming  systems,  and  so  on.  The  critical  consideration 
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which  should  be  given  to  advanced  SMS  development  is  to  avoid 
a reliance  on  serendipity  for  the  evolution  of  improved  sys- 
tems. Rather,  careful  attention  should  be  given  to  the  areas 
of  research  and  development  which  should  be  encouraged  for 
future  applications. 

III.  SYSTEM  STL'DIES 


SMS  ARCHITECTURE 

Data  communications/processing  architectures  have  under- 
gone considerable  changes  during  recent  years.  These  changes 
have  resulted  from  the  increased  capability  of  hardware  and 
better  understanding  of  communications  techniques.  For  many 
years,  the  advantages  of  distributed  architectures  were  appar- 
ent; however,  the  realization  of  effective  distributed  systems 
had  to  await  the  arrival  of  modular  computer  systems,  micro- 
processor technology,  and  a better  understanding  of  computer 
networking  strategies.  This  now  being  the  case,  not  only 
effective  distributed  systems,  but  also  federated  or  embedded 
architectures  ate  somewhat  commonplace. 

The  system  designer ;s  problem  has  changed  from  one  of 
adapting  a solution  to  an  available  architecture  to  one  of 
selecting  the  appropriate  architecture  for  a problem  solution. 
Not  only  are  the  classical  architectural  concepts  being  used, 
"hybrid"  architectures  using  aspects  of  more  than  a single 
type  are  being  implemented,  as  well  as  "custom"  architectures 
devised  for  a particular  application. 

This  freedom  of  architectural  form  allows  the  develop- 
ment of  a Stores  Management  System  concept  which  is  tailore>.l 
to  functions  and  constraints  of  the  aircraft/stores  environ- 
ment. A principal  consideration  is  tl'.e  MU -STD-1553B  multi- 
plex data  bus.  This  standard  is  an  effective  compromise  be- 
tween the  sophistication  required  for  effici  nt  communications 
links  and  the  simplicity  required  for  modularization  and 
interoperability.  In  tiiis  paper,  it  will  be  assumed  that  a 
MIL-STD-1553B  multiplex  digital  data  bus  will  be  used  for  all 
communications;  however,  the  topology  of  the  computer/commun i - 
cations  network  will  be  tailored  to  the  SMS  fanction. 

A second  set  of  assumptions  which  will  influence  an  SMS 
architecture  involves  the  physical  characteristics  of  the  air- 
craft/stores configurations  to  be  considered.  Figure  2 shows 
the  three  basic  configurations  assumed  as  representative  of 
virtually  all  aircraft/stores  which  arc  of  interest. 
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Figure  2.  Basic  Aircraft/Store  Configurations. 

A final  set  of  assumptions  considers  the  communications 
paths  which  are  required  to  accomplish  the  Stores  Management 
function.  First,  it  will  be  assumed  that  avionics  data  will 
be  required  by  the  SMS  and  therefore  data  transfer  (two-way) 
between  the  avionics  bus  and  SMS  bus  must  be  possible.  (This 
also  assumes  a bus  structure  for  the  avionics  subsystem.) 
Secondly,  all  independent  buses  will  require  a bus  controller. 
Third,  all  digital  data  interfaces  are  MIL-STD-1553B  compat- 
ible. All  units  connected  to  a single  bus  must  appear  as 
remote  terminals  and  any  SMS  remote  terminal  may  communicate 
with  any  other  SMS  remote  terminal. 

The  simplest  architectural  concept  for  SMS  consideration 
would  be  a single  SMS  multiplex  bus  with  all  related  subsys- 
tems appearing  as  remote  terminals.  This  structure  is  shown 
in  Figure  3 and  can  be  viewed  as  a "horizontal"  bus  structure. 

An  SMS  architecture  which  could  be  considered  as  a "ver- 
tical" bus  structure  is  shown  in  Figure  4.  This  architecture 
allows  independent  communication  on  three  separate,  but  inter- 
connected, SMS  buses  plus  an  interface  to  the  aircraft  avionics 
bus  and  any  weapon  buses. 

In  addition  to  the  strictly  horizontal  or  vertical  struc- 
tures, there  are  a large  number  of  "diagonal"  bus  structure 
possibilities.  In  general,  such  a diagonal  structure  would 
increase  communications  speed  at  the  expense  of  hardware  and 
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software  complexity.  One  possible  diagonal  structure  is 
shown  in  Figure  5 and  employs  a special  controller  in  order 
to  reduce  the  communications  overhead  associated  with  the 
multiplicity  of  bus  levels  in  a vertical  arrangement. 
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Figure  5.  Interbus  (Diagonal)  Bus  Structure  for  SMS. 

An  assessment  of  these  candidate  architectures  must  in- 
volve not  only  the  inherent  advantages/disadvantages,  but  also 
their  relative  importance.  In  addition,  all  relevant  technical 
aspects  of  an  overall  SMS  must  be  considered,  including  com- 
munications, hardware,  software,  and  operations  support. 

SMS  COMMUNICATIONS 


Directly  related  to  the  selection  of  an  SMS  architecture 
is  the  specification  of  the  data  communications  procedures 
which  shall  be  used.  The  problem  is  somewhat  bounded  by  the 
assumption  concerning  use  of  the  MTL-STD-1553B  multiplex  data 
bus.  However,  this  standard  still  allows  considerable  flexi- 
bility in  the  communications  protocol  which  is  employed,  espe- 
cially with  the  addition  of  a broadcast  option  in  the  1553B 
version. 

Choice  of  an  appropriate  communications  protocol  is 
generally  a compromise  between  (1)  the  time  required  for  trans- 
mission of  a complete  message  from  one  communications  terminal 
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Figure  6.  Aircraft  Technology  Trends  Toward  Integrated 
Systems . 

The  core  of  the  Stores  Management  System  would  include 
the  SM-BUS  with  associated  terminals  and  the  STA-BUS  with  its 
associated  terminals.  In  a development  sense,  the  store  sus- 
pension architecture  as  well  as  weapon  architecture  would  be 
the  responsib  lity  of  the  appropriate  development  programs. 
Central  to  the  interoperability  features  would  be  a standard 
multiplex  data  bus  interface,  communications  protocol,  and 
software  structure.  These  concepts  are  presently  being  em- 
ployed at  the  avionics  bus  level  and  the  proposed  architec- 
ture woul  d require  similar  communications  in  a nested  arrange- 
ment. The  communications  rate  problem  is  encountered  when 
data  transfers  are  required  across  a number  of  bvis  levels. 

In  this  situation,  the  efficiency  provided  by  the  bus  controller 
units  in  transferring  information  becomes  critical.  Bus  con- 
troller capacity  is  also  the  issue  when  considering  the  over- 
head associated  with  data  transfer  between  and  two  bus  levels. 

There  are  a number  of  technological  and  operational  con- 
siderations which  tend  to  support  the  investigation  of  a 
nested  architecture.  First,  the  nature  of  stores  management 
communications  is  such  that  the  necessity  for  transferring 
large  volumes  of  data  at  high  rates  across  several  bus  levels 
does  not  presently  exist.  In  the  event  that  future  require- 
ments dictate  such  a need,  a low-risk  posture  is  afforded  by 
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the  potential  benefits  of  technoloqical  advances  in  fiber- 
optics  links,  component  speeds,  memory  capacities,  and  pro- 
cessor throughput  capabi 1 i t ies . 

Efficient  control  of  overall  SMS  eommunicat ions  will  be 
a formidable  pi'oblem.  This  control  will  resivie  principally 
in  SM-BUS  level  components  but  will  be  distributed  to  a lame 
extent  among  station  level  components  as  well  as  lower-level 
processing  systems,  lltimately,  the  effectiveness  of  the  con- 
trol schemes  will  depend  in  large  part  on  the  software  striu 
ture  adopted  during  the  conceptual  design  stages. 
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CONCLUSIONS  AND  RECOMMENDATIONS 


The  development  of  a wide  variety  of  aircraft  and  stores 
to  fulfill  the  Air  Force  mission  has  created  the  need  for  so- 
lutions to  problems  involving  interoperability.  These  prob- 
lems concern  not  only  the  Air  Force,  but  the  entire  Department 
of  Defense  and  the  NATO  nations. 

This  report  has  described  the  technical  aspects  of  a 
Stores  Management  System  for  advanced  applications  which  treats 
the  interoperability  issue  as  a design  focal  point.  In  doing 
so,  several  critical  technical  aspects  are  exposed  for  consider 
ation.  The  computer/communications  network  which  would  be  best 
suited  for  the  Stores  Management  function  is  one.  A nested 
architecture  has  been  described  which  has  an  inherent  physical 
compatibility  with  the  aircraft/stores  structure  and  is  con- 
sidered to  be  the  most  suitable  scheme  for  immediate  investi- 
gation. 

The  selection  of  an  architecture  is  not  independent  of 
the  optimum  communications  protocol  for  a Stores  Management 
System.  It  is  pointed  out  that  both  synchronous  and  asynchron- 
ous communications  schemes  bear  consideration.  The  speed  ad- 
vantages of  an  asynchronous  (e.g.,  interrupt-driven)  system 
must  be  compared  with  the  greater  simplicity  of  a synchronous 
(e.g.,  command-response)  system.  Other  tradeoffs  include  con- 
sideration of  additional  hardware,  testability,  compatibility 
with  1553  multiplex  standard,  and  so  on. 

The  selection  of  an  SMS  communications  protocol,  in  turn, 
will  have  a great  effect  on  the  complexity  of  the  required 
software.  The  adaptive  SMS  whicli  is  suggested  in  the  previous 
section  would  rely  heavily  on  the  effective  management  of 
software  development  and  mainenance  efforts.  A sufficiently 
complex  software  structure  would  pose  a threat  to  the  basic 
feasibility  of  such  an  attempt  to  enhance  aircraft/stores 
interoperability  features. 
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ABSTRACT 

This  paper  describes  the  application  of  multiplexing 
techniques  within  the  Navy's  Advanced  Integrated  Display 
System  (AIDS) . The  AIDS  project  under  the  direction  of  the 
Naval  Air  Development  Center  is  currently  in  the  Advanced 
Development  Model  phase.  General  Electric  is  system  con- 
tractor with  Intermetrics,  Inc.  the  associate  contractor 
for  software  development.  The  goal  of  AIDS  is  to  develop 
a modular  set  of  displays  and  controls  along  with  associ- 
ated processing  and  data  multiplexing  elements  that  can  be 
applied  to  all  future  Navy  aircraft.  Objectives  arc  im- 
proved pilot  performance,  reduced  weight  and  Life  Cycle 
Cost  and  improved  mission  reliability.  The  extensive  uti- 
lization of  multiplexing  is  a key  factor  in  helping  to 
achieve  all  of  these  objectives.  Multiplexing  will  be 
applied  in  three  distinct  areas:  (1)  narrowband  serial 

digital  (i.e.,  1553B) , (2)  wideband  video  suitable  for 

transmitting  TV  Raster  formatted  data,  and  (3)  high-speed 
parallel  digital  suitable  for  transmitting  data  between 
digital  modules  on  a common  back  panel. 

The  Advance  Development  Model  (ADM)  of  AIDS  will  be 
implemented  with  currently  available  technology.  It  will 
be  used  to  validate  system  concepts  and  software.  It  will 
also  be  designed  with  sufficient  flexibility  so  that  ad- 
vanced multiplexing  technologies  can  be  incorporated  and 
demonstrated  as  they  become  available. 
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I. 


INTRODUCTION 


Advanced  Integrated  Display  System  (AIDS)  is  a U.S. 

Navy  project  currently  in  Advanced  Development  (Figure  1). 

It  is  directed  by  the  Naval  Air  Development  Center  (NADC) 
with  General  Electric  Company  responsible  for  system  develop- 
ment and  Intermetrics,  Inc.,  responsible  for  software  devel- 
opment. Its  objectives  are  improvements  in  performance,  re- 
liability, weight  and  life  cycle  costs  in  the  display/controls 
of  future  Navy  aircraft.  This  paper  first  describes  briefly 
the  basic  AIDS  configuration  and  program  plan  as  well  as  the 
objectives  of  AIDS  and  how  their  achievement  is  dependent  on 
the  use  of  multiplexing  techniques.  The  subsequent  portions 
of  the  paper  describe  in  turn  the  three  areas  where  multiplex- 
ing is  applied  in  AIDS;  (1)  Narrow  Band  Serial  Digital, 

(2)  Wide  Band  Video,  and  (3)  High  Speed  Parallel  Digital. 

Each  of  these  sections  addresses  the  requirements,  the  planned 
architecture,^  the  initial  ADM  implementation  and  where  appro- 
priate some  growth  options  that  are  availvable. 

II.~  AIDS  DESCRIPTION 

Figure  2 is  a cockpit  view  of  the  basic  AIDS  configura- 
tion. The  pilots  basic  displays  include  the  Heads-Up  Display 
(HUD) , Vertical  Situation  Display  (VSD) , Horizontal  Situation 
Status  Display  (HSD)  and  two  identical  Status  Advisory  Dis- 
plays (SAD).  A Helmet  Mounted  Display/Sight  is  optional. 
Principal  control  elements  are  the  Mode  Selector  Panel  (MCP) 
and  the  Integrated  Control  Panel  (TCP)  which  provides 
switches  with  programmable  legends.  These  legends  are  dis- 
played using  Liquid  Crystal  Display  (LCD)  technology.  Another 
cockpit  element  not  shown  on  Figure  2 is  the  Briefing  Informa- 
tion Entry  Device  (BIED)  which  allows  preflight  entry  of  mis- 
sion data  via  a magnetic  cartridge  device. 

An  optional  sensor  station  is  also  shown  which  would, 
for  example,  be  applicable  to  missions  envisioned  for  the 
Navy's  V/STOL  A.  The  objective  here  is  to  maximize  hardware 
commonality  between  pilot  and  sensor  station  displays/controls . 

Figure  3 is  a highly  simplified  block  diagram  of  the 
total  AIDS  system.  All  display/control  electronics  outside 
the  cockpit  will  be  housed  in  Modular  Integrated  Display 
Electronics  Racks  (MIDER) . Connection  between  the  MIDERS  and 
the  cockpit  elements  of  AIDS  and  between  the  MIDERS  and  other 
Avionic  systems  will  be  via  multiplex  systems  both  narrow 
band  digital  (1553B)  and  wide  band  video.  It  will  be  noted 
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that  communication  to  the  imaging  type  cockpit  displays 
involves  both  1553B  and  the  wide  band  multiplex  systems. 
Communication  to  all  other  cockpit  units  is  via  1553B  only. 

III.  AIDS  PROGRAM  PLAN 

Figure  4 summarizes  the  AIDS  background  and  project 


schedule.  Nvimerous  exploratory  development  projects  over 
several  years  provided  the  background  for  the  AIDS  system 
design  which  was  initiated  in  1976.  This  system  design 
identified  the  most  promising  technologies,  established  the 
baseline  system  configuration  described  herein  and  produced 
specifications  for  the  Advanced  Development  Model.  This  ADM 
is  now  in  the  early  phase  of  implementation.  Human  factors 
considerations  are  a vital  aspect  of  AIDS.  The  AJM  when 
completed  in  1981  will  be  used  at  NADC  for  integration  with 
other  advanced  avionics  systems  and  to  support  human  engineer- 
ing experiments.  It  will  also  be  designed  with  sufficient 
flexibility  to  later  incorporate  advanced  technologies. 

These  will  likely  include  such  advances  as  color  and  flat 
panel  displays,  solid  state  mass  memory  and  fiber  optics  data 
transmission. 

IV.  AIDS  OBJECTIVES 

Figure  5 illustrates  the  primary  AIDS  objectives  as 
well  as  their  relationship  with  several  concepts  that  are 
fundamental  to  the  AIDS  concept.  Multiplexing  is  one  of 
these  concepts  and  it  will  be  seen  that  either  directly  or 
indirectly  the  use  of  multiplexing  contributes  to  the 
achievement  of  all  of  the  primary  AIDS  objectives. 

V.  AIDS  CONFIGURATION 

Figure  6 shows  in  greater  detail  the  AIDS  baseline  con- 
figuration and  illustrates  some  of  the  architectural  features 
that  have  an  impact  on  the  requirements  for  multiplexing. 

One  of  these  features  is  the  distribution  of  processing  using 
microcomputers,  which  has  the  effect  of  reducing  buss  traffic. 
For  example  each  unit  will  control  its  internal  self  test  via 
its  microcomputer  and  report  only  summary  status  to  the  AIDS 
control  processor.  Another  feature  is  the  location  of  symbol 
generators  at  the  displays  where  feasible.  The  only  symbol 
generators  located  outside  the  displays  will  be  those  for 
complex  in-raster  symbology  associated  with  the  imaging  dis- 
plays. These  will  be  located  in  the  MIDER  and  their  output  is 
transmitted  to  the  displays  via  a wide  band  video  buss.  Con- 
sequently the  traffic  on  the  internal  AIDS  1553B  is  relatively 
light. 
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Figure  7 depicts  AIDS  from  a larger  perspective  showing 
its  interfaces  with  other  Navy  Avionic  subsystems  many  of 
which  are  also  in  the  Advanced  Development  phase.  It  will  be 
noted  that  the  interfaces  consist  of  the  wide  band  multiplex 
carrying  sensor  video  and  the  main  avionics  buss  (1553B)  for 
transmitting  serial  digital  data.  The  postulated  avionics 
configuration  does  not  include  a central  computer;  rather  it 
is  assumed  that  processing  is  distributed  cimong  the  various 
subsystems.  AIDS  therefore  includes  sufficient  processing 
and  memory  capacity  to  perform  all  display/control  functions. 

The  result  is  that  the  data  rate  between  AIDS  and  the  main 
avionics  buss  is  low  relative  to  what  it  would  be  if  display/ 
controls  computations  were  being  performed  in  a Central 
Computer . 

VI.  NARROW  BAND  MULTIPLEXING 

Figure  8 summarizes  the  requirements  for  narrow  band 
multiplexing  both  within  AIDS  and  between  AIDS  and  other  sub- 
systems. It  is  expected  that  the  broadcast  mode  will  be 
utilized  for  functions  such  as  distributing  data  of  interest 
to  several  users,  distributing  mission  time,  etc.  Figure  9 
shows  the  planned  architecture  for  these  1553B  busses.  Re- 
dundant busses  are  provided  to  insure  that  no  single  failures 
will  result  in  a total  failure  of  AIDS.  Cockpit  units  are 
interfaced  to  both  1553B  busses:  each  unit  will,  under  non- 
degraded  conditions,  be  assigned  to  one  of  the  two  busses. 

The  second  buss  is  used  for  degraded  modes  of  operation. 

Figure  10  is  the  initial  terminal  implementation  in  the 
AIDS  ADM  using  currently  available  components.  In  so  far  as 
possible  the  design  will  factor  in  the  configuration  of  the 
BID  chips  under  development  such  that  later  versions  of  AIDS 
might  incorporate  these  chips.  Figure  11  summarizes  other 
possible  growth  considerations  in  the  1553B  area. 

VII.  WIDE  BAND  VIDEO  MULTIPLEXING 

Figure  12  is  a summary  of  the  requirements  including 
projected  growth  for  the  wide  band  video  multiplex  buss. 

Figure  13  shows  the  planned  architecture  where  again  redun- 
dancy is  provided  to  prevent  catastrophic  AIDS  failures.  The 
system  will  initially  be  implemented  with  readily  available 
commercial  components  to  provide  a low  cost  vehicle  available 
at  an  early  date  that  can  be  used  to  demonstrate  system  con- 
cepts. At  a later  date  this  system  can  be  updated  to  incorpor- 
ate more  advanced  technologies  such  as  fiber  optics  (Figure  15) . 


VIII.  HIGH  SPEED  PARALLEL  MULTIPLEXING 


The  requirements  summarized  in  Figure  16  represent  those 
for  the  AIDS  Modular  Integrated  Display  Electronics  Rack 
(MIDER) . The  implementation  shown  in  Figure  17  provides  a 
much  greater  data  transfer  capability  than  is  required  by 
AIDS  ( 200K  words/sec) . This  high  speed  multiplexing 

approach  is  not  unique  to  a display  system;  it  could  be 
applicable  to  other  digital  avionics  employing  an  integrated 
rack  approach. 

IX.  SUMMARY 

(Figurf'  18).  The  AIDS  ADM  makes  extensive  use  of  mul- 
tiplexing in  order  to  achieve  the  system  objectives.  While 
in  some  areas  readily  available  technology  will  be  initially 
used,  the  designs  will  be  sufficiently  flexible  to  accommo- 
date advanced  technologies  such  as  fiber  optics  as  they 
achieve  a more  mature  status. 
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MULTIPLEX  BUS  FOR 

INTEGRATED  AVIONICS  MANAGEMENT  SYSTEMS 


Merrill  T.  Ludvigson 
Rockwell-International 
Collins  Government  Avionics  Division 
Cedar  Rapids.  Iowa 

In  my  discussion  of  the  use  of  the  MIL-STD-1553  multiplex  bus  as  an 
integration  tool  for  Avionics  Management  systems,  I will  begin  by  taking  a 
look  at  multiplexing  from  an  historical  perspective,  then  proceed  to  the 
main  body  of  the  paper  to  the  use  of  multiplexing  in  Avionics  Management 
Systems  and  follow  with  some  conclusions  and  reconmendations. 

From  an  historical  perspective,  I would  like  to  review  briefly  the  moti- 
vation for  multiplexing,  discuss  some  of  the  constraints  which  have  limited 
the  breadth  of  application  of  multiplexing  and  review  the  experience  gained 
by  Rockwell -Coll ins  and  others. 

I am  sure  that  we  all  recognize  the  important  role  multiplexing  can 
play  to  reduce  complexity  and  weight  of  aircraft  interconnect  and  the  role 
it  can  play  to  improve  integration  opportunities  with  growing  digital  pro- 
cessor applications.  Another  important  role  is  that  of  the  integration  of 
controls  and  displays  to  simplify  the  relationships  between  crew  station  con- 
trol/display functions  and  aircraft  systems  being  managed.  But  perhaps  one 
of  the  most  important  roles  of  all  is  to  provide  the  flexibility  needed  to 
allow  the  weapon  system  to  be  upgraded  for  changing  requirements.  Funding 
is  getting  tighter,  yet  technology  is  progressing  at  an  ever  increasing  rate 
while  the  acquisition  time  appears  to  be  lengthening.  All  of  this  only  serves 
to  increase  the  probability  that  threats  will  change  before  a weapon  system 
becomes  operational. 


But  certain  constraints  exist.  One  is  the  availability  of  MIL-STD-1553 
conpatible  equipment  and  the  other  is  the  availability  of  suitable  industry 
standards. 

But  why  do  the  constraints  exist?  First  of  all,  previous  weapon  systems 
utilized  multiplex  technology  for  limited  subsystem  application.  Airframss 
developed  centralized  systems  and  utilized  similar  but  unique  bus  techniques, 
and  we  as  vendors  responded  to  specific  program  specifications.  As  a result, 
integration  required  a wide  variety  of  special  adapters  and  concentrators  to 
interface  widely  variant  sensors  and  standard  avionics  equipment. 

But  obviously  considerable  experience  has  been  gained  from  the  systems 
and  equipment  numerous  airframes  and  avionics  suppliers  have  produced  to  date. 
The  Collins  background  has  been  aided  from  the  vantage  point  of  a supplier  of 
multi-user  product  lines  which  include  Comnv/Nav  equipment,  cockpit  management 
systems,  flight  instruments;  and  as  a subsystem  contractor  for  such  programs 
as  Integrated  Avionics  Control  System  (lACS),  the  F-15  digital  HSI  (Horizontal 
Situation  Indicator),  on  the  space  shuttle  digital  HSI  program  and  a numoer 
of  aircraft  flight  directors.  Collins  background  also  includes  experience 
as  an  avionics  integrator  in  such  programs  as  the  HU-25A,  Medium  Range  Sur- 
veillance Aircraft  (MRS)  and  the  USCG  HC-130H  Cockpit  Management  System. 
Playing  these  multiple  roles  has  given  Collins  a varied  insight  into  such 
important  considerations  as  system  design  management  for  both  hardware  and 
software,  system  partitioning  for  integratability  and  for  functional  inte- 
grity, bus  utilization  for  bandwidth  conservation  and  for  redundancy,  the 
impact  multiplexing  has  on  product  line  standards  and  the  cost  of  ground 
support  equipment,  and  the  detailed  specifications  required  to  assure  inte- 
gration of  various  suppliers  equipment. 

To  properly  address  the  application  of  the  multiplex  bus  as  an  Avionics 
l^nagement  System,  we  will  address  such  factors  as  system  content,  operational 
considerations,  that  is,  those  special  considerations  necessary  to  see  that 
that  the  system  performs  the  desired  functions  when  everything  is  working; 
and  system  integrity,  that  is,  those  considerations  necessary  to  see  that  it 
can  perform  when  something  fails.  We  will  then  review  four  examples  with 
these  considerations  in  mind. 
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The  first  thing  one  must  do  is  to  determine  the  system  contents.  What 
makes  up  a shipset?  There  may  be  a diversity  of  functions  such  as  control 
and  display  and/or  integration  of  entire  subsystems,  such  as  communications, 
navigation,  weapons,  or  flight  control.  One  must  identify  such  factors  as 
multiple  operator  station  capability  and  be  aware  of  the  degree  of  compati- 
bility of  the  elements  to  be  managed  to  the  bus  concept. 

The  operational  considerations  have  to  do  with  such  factors  as  operator 
manipulation  or  the  times,  responses,  and  priorities  related  to  the  human 
interface,  as  well  as  such  purely  hardware  considerations  as  system  perfor- 
mance via  the  bus,  that  is,  bus  loading,  delays,  or  timing,  and  what  part 
partitioning  may  play  in  resolving  these  and  other  problems. 

The  system  integrity  considerations  include  identifying  the  survivability 
needs  of  the  various  components  or  subsystems  and  determining  what  role  is 
played  by  the  management  subsystem.  How  can  partitioning,  redundancy,  and 
the  use  of  reversionary  modes  be  used  to  ensure  system  integrity?  Bus  pro- 
tection is  an  important  consideration  which  can  benefit  from  such  techniques 
as  hardware  or  software  time  out  and  by  physically  protecting  the  bus  by  the 
use  of  external  bus  couplers  and  physical  separation  of  the  buses. 

The  first  of  the  four  systems  I will  describe  is  the  U.  S.  Aniiy  Integrated 
Avionics  Control  System  (lACS)  program  shown  in  figure  1.  You  will  note  the 
special  emphasis  given  to  the  bus  so  that  the  similarity  between  this  and 
other  systems  is  readily  apparent.  The  system  design  is  based  on  MIL-STD- 
1553A  and  provides  a dual  bus  for  redundancy  and  redundant  bus  controllers. 
Interface  adapter  modules  are  used  for  non -compatible  avionics  equipment  and 
backup  system  computers  are  provided.  You  will  also  note  interface  capability 
with  doppler  radar,  the  mission  computers,  and  other  equipment,  if  necessary. 

The  lACS  is  a cockpit  management  system  which  currently  performs  con- 
trol display  functions.  (See  figure  2)  While  the  current  implementation 
includes  a primary  control  unit,  secondary  control  unit,  and  a status 
panel,  the  system  can  accoimiodate  another  primary  control  unit  and  two  more 
status  panels.  The  shipset  of  equipment  being  managed  is  shown  and  none  of  the 
equipment  have  been  designed  to  be  MIL-STD-1553  compatible. 
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The  operational  considerations  are  shown  In  figure  3.  The  operator 
Interface  designs  are  the  result  of  extensive  human  factors  background  and 
analysis.  The  primary  control  unit  Is  a multipurpose  control  display  unit 
which  utilizes  multipage  display  capability.  A secondary  control  unit  is 
provided  with  reduced  capability.  More  than  one  primary  control  unit  may  be 
used  with  the  system.  If  necessary.  The  lACS  configuration  Is  capable  of 
dedicated  bus  operation  and  Is  also  capable  of  dynamic  bus  allocation  usinr 
an  external  bus  controller.  The  bus  loading  Is  less  than  lOX  with  a service 
rate  of  10  times  per  second.  The  critical  timing  Is  associated  with  system 
reaction  to  operator  keystroke  or  function  selection. 

The  Cockpit  Management  System  (CMS-80)  for  the  Medium  Range  Surveillance 
(MRS)  aircraft  Is  shown  In  figure  4.  You  will  note  the  similarity  of  the 
basic  bus  architecture.  You  may  note  also  the  addition  of  several  new  equip- 
ments, such  as  the  HF,  OME,  and  TACAN  and  the  navigation  computer  which.  In 
turn.  Interfaces  with  the  navigation  sensors  and  the  mission  package. 

The  basic  architectural  approach  for  the  MRS  is  also  based  on  MIL-STD- 
1553A  with  dual  bus  for  redundancy  and  dynamic  allocation  for  efficient  bus 
tulllzatlon.  In  this  application,  the  bus  Is  used  for  map  transfer  from  the 
navigation  conputer  to  the  Control  Display  Unit  (CDU). 

As  shown  In  figure  5,  ihe  system  performs  the  control  and  display  func- 
tions for  the  flight  and  fuel  management  as  well  as  the  communications  and 
navigation  equipment.  Interface  adapter  modules  are  necessary  for  all  equip- 
ment because  none  of  them  are  directly  MIL-STD-1553  compatible. 

The  MRS  operational  considerations  are  shown  in  figure  6.  The  operator 
Interface  approach  for  the  MRS  Is  similar  to  the  Implementation  of  the  U.  S. 
Amy  lACS  program.  It  utullzes  three  identical  cockpit  control  displays 
(CCD)  and  a dedicated  control  display  unit  (CDU)  for  mission  scenario  manage- 
ment. The  MRS  system  Is  also  capable  of  dedicated  bus  operation  and  capable 
of  dynamic  bus  allocation  using  the  external  bus  controller.  The  bus  loading 
Is  less  than  lOX,  with  service  required  at  10  times  per  second.  The  critical 
timing  Is  associated  with  system  reaction  to  operator  keystroke  or  function 
selection.  The  dynamic  bus  allocation  Is  used  to  service  the  navigation 
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computer  unit  (NCU)  and  the  control  display  unit  (CDU)  for  symbolic  map  dis- 
play. 

The  MRS  system  Integrity  considerations  are  shown  In  figure  7 and  Incor- 
porate 

- redundant  controls  and  displays 

- redundant  bus 

- redundant  bus  controllers 

- partitioning  determined  from  the  survivability  needs. 

Another  system  which  will  be  described  briefly  Is  the  U.  S.  Coast  Guard 
HC-130H  program  shown  In  figure  8.  This  Is  an  operational  system  already 
flying  In  the  Kodiak  area.  You  will  note  a great  deal  of  similarity  to  the 
MRS  except  now  the  Inertial  Navigation  System  and  the  h-f  filters  have  been 
added  to  the  system  complement  and  the  navigation  computer  and  its  dedicated 
control  display  unit  have  been  deleted. 

The  C-130  is  basically  a subset  of  the  MRS  design.  It  uses  the  same 
system  coupler  controls,  cockpit  control  displays,  and  remote  readout  units. 

It  utilizes  a dual  bus  for  redundancy  with  redundant  bus  controllers  and  in- 
terface adapter  modules  for  unique  equipment  complement.  The  system  is  used 
for  control  and  display  of  the  coitmuni cations  and  navigation  subsystem. 

My  last  example  is  the  GPS/GDM  system  as  shown  in  figure  9.  As  can  be 
seen  while  the  bus  architecture  looks  the  same  much  more  of  the  system  ties 
directly  to  the  bus.  The  GPS/GDM  is  a test  bed  currently  flying  in  the  Yuma 
area  as  part  of  the  GPS  evaluation  test  program.  The  MIL-STD-1553A  functions 
performed  in  the  GDM  included  the  control /display  functions  for  the  receiver, 
the  inertial  navigation  system  (INS),  and  the  high  performance  antenna  assembly. 
It  also  served  to  transfer  navigation  data  to  the  navigation  computer  in  the 
form  of  pseudo  range  and  range  rate  from  the  receiver  controller,  inertial  nav 
data  from  the  INS,  altitude  data  from  the  altimeter  end  attitude  data  from 
the  navigation  computer  to  the  high  performance  antenna  assembly.  In  the  GDM 
system,  MIL-STD-1553  was  used  to  provide  computer-to-computer  data  transfer; 
it  transferred  time  tagged  data  from  the  INS  and  utilized  service  rates  which 
varied  with  function  up  to  50  Hz  update  rate  for  the  high  performance  antenna 
assembly. 
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In  conclusion,  while  the  MIL-STD-1553  applications  are  very  broad,  the 
basic  architecture  is  essentially  the  same,  and  the  architectural  approach 
can  be  and  is  tailored  quite  easily  to  meet  system  needs  determined  by  such 
consideration  as: 

- functions  performed 

- survivability  needs 

- operator  needs,  and  so  forth. 

We  have  concluded  that  while  the  architecture  is  better  served  by  bus 
controllers  as  an  independent  function  for  large  systems,  they  can  be  inte- 
grated with  subsystem  hardware  for  limited  subsystems  to  conserve  hardware, 
weight,  and  cost.  We  have  also  found  dynamic  bus  allocation  can  be  very  use- 
ful to  introduce  more  sophisticated  control  requirements  when  the  system 
demands  it. 

We  believe  that  we  should  resist  the  temptation  to  add  special  features 
to  standard  equipment  for  a particular  weapon  for  a particular  weapon  system. 
Beyond  MIL-STD-1553A,  we  believe  that  there  is  a real  need  for  additional  de- 
finition, that  is,  a specification  which  will  provide  subcontractor  interface 
control  and  hardware  compatibility  and  which  will  actually  define  the  protocol 
and  timing,  etc.  Of  course,  in  view  of  the  large  commitment  made  to  compatibl 
MIL-STD-1553A/B  hardware,  future  definition  will  have  to  be  upward  compatible. 


FIGURE  2.  lACS  SYSTEM  COMPOSITION 


FIGURE  3.  lACS  OPERATIONAL  CONSIDERATIONS 


FIGURE  4.  MRS  ARCHITECTURAL  APPROACH 
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FIGURE  6.  MRS  OPERATIONAL  CONSIDERATIONS 
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FIGURE  9.  GPS/GDM  ARCHITECTURAL  APPROACH 


PRECISION  ATTACH  ENHANCEMENT  INTEGRATION 
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MJLTIPLEX  CONTROL  OF  AIRCRAFT  SUBSYSTEMS 

F.  E.  Funke 

Los  Angeles  Division 
Rockwell  International 
El  Segundo,  California 


ABSTRACT 

The  Electrical  Multiplex  (EMUX)  System  as  developed  for  the  B-1  Bomber 
represents  one  of  the  first  extensive  applications  of  time  division 
multiplexing  for  controlling  power  to  subsystems,  data  transfer  between 
subsystems,  and  for  control  of  subsystem  operation.  This  paper  reviews  the 
system  requirements,  configuration,  and  the  operation  of  the  EMUX  system 
including  the  provision  for  automatic  load  management  and  transfer  of  data 
to  the  on-board  integrated  test  system.  The  system  design  approach  was  to 
make  maximum  use  of  multiplexing  where  weight  or  cost  effective  except  where 
prohibited  by  safety  of  flight  considerations.  The  EMUX  use  of  redundancy  is 
described  together  with  fault  tolerance  concepts  and  survivability/vulnerability 
considerations.  Interface  compatibility  with  subsystems  was  assured  through 
standardization  and  interface  control  documentation.  This  was  essential  as 
practically  all  aircraft  subsystems  utilized  EMUX  functions  and  had  to  be 
integrated  with  EMUX.  Future  improvements  were  planned  for  the  B-1  Production 
Program  which  included  redesign  to  reduce  the  recurring  unit  cost  of  EMIIX  and 
the  use  of  solid  state  power  controllers.  Various  design  approaches  are  under 
consideration  for  future  tactical  and  strategic  aircraft  which  would  enchance 
the  weight  savings  and  cost  effectiveness  of  multiplex  control  of  aircraft 
subsystems. 


1.  iNTUonucrioN 


■Vii  electrical  multiplex  system  was  conceived  for  the  H-1  tomher  early 
in  lire  because  it  was  realized  that  weight  ;md  vohmie  penalties  would  result 
if  conventional  wiring  teclmiques  and  relay  logic  were  used  to  handle  the 
multiplicity  of  subsystem  control  fiuictions,  the  control  of  electrical  power 
to  subsystems,  :md  the  transfer  of  digital  data  between  and  within  subsystems. 
Therefore,  an  extensive  use  of  multiplexing  was  employed  in  the  aircraft  which 
resulted  in  the  following  benefits. 

1.  Reduced  wire  harness  weight,  vohmie,  ami  fabrication  cost. 

2.  Provided  flexibility  in  control  logic  pennitting  system  changes 
with  minimal  imj-iact  on  wiring. 

I’rovided  increased  reliability  via  redundancy  where  needed. 

4.  Reduced  maintenance  and  clieckout  via  the  on-board  checkout 
system. 

The  aii'craft  was  partitioned  into  three  multiplex  systems.  Hie  electrical 
multiplex  system  IIMIXI , addressed  in  this  paper,  is  used  principally  to 
(1)  control  power  to  subsystems,  (21  provide  Roolcim  logic  processing  of 
subsystem  control  signals,  ;md  (.^1  jirovide  data  transmission  chiuinels  for 
aircraft  systems.  'ITie  Central  Integrated  Test  System  (CI  TS)  incoi-jxirates 
multiplexing  to  monitor  all  aircraft  subsystems  in  flight  luid  on  tlie 
di.sp lay/ record  failed  modes  of  operation,  ami  fault  isolate  to  tl'.o  l.Rll  level. 
Hie  Avionics  Multiplex  (AMllX)  integrates  the  Avionics  Control  luiits  (conniuters) 
with  the  Navigation  ;ind  Weapon  hcliverv  Subsystems,  Stores  Muiagement  Sub- 
system ;uid  associated  controls  <md  displays  for  the  Offensive  and  llefensive 
system  operators. 

This  jiapcr  describes  the  IMIX  system  requirements,  configuration,  ;uid 
operation  of  the  I'J'IUX  system  followed  by  the  system  design  approach  and 
resulting  applications  to  the  various  aircraft  subsystems,  'llie  improvements 
and  innovations  plaiuied  for  future  aircraft  multiplex  systems  is  also  covered. 
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SVSTIW  W-;gillRl^\TS 


1 1 . 


ions 

In  vorv  sim|)k'  teims,  the  system  reqiiiroiiK'nt  tor  1M1\  is  to  proviilo  a 
liijihly  reliable,  weijtht,  ;uk1  eost  elleetive  substitute  lor  barJuireJ  eontrol, 
data  transfer,  and  eontrol  lojtie.  ^^u'e  speei  f ieal  Iv,  MMUX  must  jn'rlonii  the 
fo  1 1 ow  i njj  f inie  t i on  s : 

1.  txintrol  ;uk1  iiK^nitor  distribution  of  eleetrieal  ixwer  to  aiivratt 
subsystems. 

fo  perfonn  this  fiuietion,  bMl\  must  eontrol  and  iiKMiitor  the  ojH'rat  ion 
of  jxiwer  eontrol  luiits  ;md  nKmitor  the  statvis  of  *lu'  assoeiated 
eireuit  breakers. 

2.  Provide  eontnil  sijtnals  to  and  between  aiivraft  sultsystem  l.KU's. 

I'o  |ierfonn  this  fiuietion,  Ij'HX  must  s;uii|ile  diserete  input  signals, 
proeess  the  sii;nals  in  aeeordimee  with  pre-pi\\yr;uiiiied  IWlean  Uycie, 
and  supply  the  neeessarv  output  siytnals  to  subsystem  IRU's. 

.X.  I'ransfer  data  between  subsystems  ;md  within  subsystems. 

fo  perfonn  this  fiuietion,  PMIX  must  aet  as  a eomiiKin  earrier  for 
the  transfer  of  serial -diyiital  data  between  subsystem  lRl''s.  In 
addition,  I'MIX  must  be  able  to  eonvert  serial  digital  data  to 
parallel  diserete  data  ;uivl  viee  versa. 

4.  Pi-ovide  automat  ie  load  m;uia>;enK'nt . 

IMIX  must  automat  ieal  ly  diseonneet  tlie  aireraft  tx-iwer  loads  in 
resiKinse  to  reduet  ion  of  eleetrieal  power  peneratinp  eapabiliti, 
eleetrieal  system  ill-health,  or  aireraft  operational  nxxles. 

5 . Perform  so  1 f - test . 

IMUX  must  eont iiUKXisly  jx'rfomi  self-test  o*'  its  own  intenial 
funetions  and  autonvit  ieal  Iv  shift  to  rediuidiuit  intenial  eireuits 
when  neeessan-. 
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I'nn  ilk-  v.l.it;i  to  tlio  I'oiifr.il  Into.cratoJ  lost  Svstom  n'll'Sl. 

Iho  INlllX  must  stiiro  all  vlata  t raiismi  t tovi  \\ithin  its  svstom  in  a 
moinorv  iJiioli  oan  Iv  intono^atod  l'\  tho  ill'S  via  a sorial  vlicital 
intortaoo.  I'll'S  usos  tho  vlata  availablo  from  l.'IHV  tor  inflight 
iiKMiitorinit  aiui  orouiki  tost  iM'  tho  aiivraft  suhsvstoms. 

I'xocuto  tost  ooimianvis  fnmi  I'l  IS. 

IXirini;  i^rouiul  ro.ivlinoss  tost  inc,  I'l  IS  oont  i.onros  tho  airvralt  for 
tost  aiivl  oxooutos  manv  of  tho  roviuirovl  tost  finu-t  ions  hv  soiulinj; 
v'v'iiiaanvl  vlata  tv'*  tlu'  l.Mll\  tht\>iii;li  a soi'ial  vliv;ital  intortaoo, 

in.  i:\rvhiiiiiis 

K’  v".irr\  i''ut  tho  lv'iv>kMn>;  tunot  ions,  tho  IMllX  s'.sti'in  inv‘v*riv*iatos  tho 
folKnviu^  tomin.ils  .nivl  vl.it. i busos: 

1.  IvOiiK'to  tonninals. 

fho  ri'iiii'to  tonuin.ils  I'lv’vivlo  inj'vU  .invl  iMiti'iit  signal  ooiul  i t ii'*n  inc 
to  intorl.K'v'  \vith  tho  .lirv'r.ilt  siibs\  st  I'liis . I'ho  roiiK'ti'  tonain.ils 
.iiv  o.ii'.iblo  v'l'  two  i\a\  vl.it.i  t r.insmi  ss  ivy'll  with  tho  control  bo\os 
thus  00*11 1 nil  li'rsi  vnor  tho  multiplox  vl.ita  biisi's. 

iiintrol  bo\os. 

iv'uti'v'l  K'\os  tv'v  bus  ovuit  rol  1 ors ' oiintivil  tho  v'limrianvl  ivsj'v'nso 
tr.ittiv'  v’li  till'  vl.it.i  busos  .iiul  prov  ivlo  tlu'  n'.'00s>.ir\  liipiv'  pr.'oossino, 
to  vloioli'i*  oomuKiHvl  vl.it.i  basovl  on  tlio  input  vl.it.i  rovoivovi.  I'ho  loiitii'l 
bv'Xi's  iiK'nitv'r  tlio  soli  tost  vl.it.i  aiul  ho.iltli  I'f  tho  romi'tc  toiniinals 
•iiivl  oan  take  iiooossari  .lotion. 

.1.  I'l  is  intortaoo  toniiin.il. 

Iho  ri  IS  (i'll  intorl'.ioo  toixiin.it  stvuvs  all  input  aiul  viiitput  tr.iffio 
transmit  tOvl  ini  tho  vl.it.i  buses  m'  .is  to  ruiko  tho  ourront  vl.it.i  trai't'io 
aiivl  st.itus  ol  tho  siibsxstoms  usin>’,  IXIHX  .nailablo  to  tho  roiitral 
Into^ratovl  lost  Svstv'm.  llio  i'l  boxos  .ilso  aovopt  sori.il  vli^it.il 
ooiiim.invi  vl.ita  I'rori  I'l  IS  (vliirni;;  v'ort.iin  ^riuiiKl  oporationol  iiivivlosl 
.iiul  I'l'l.n  sill’ll  oomm.invis  to  t lu'  oonti'v'l  boxos  tor  oont  rol  1 i iij: 
siibsxstoms  aiivl  oonf ivtiir iiii;  tho  .liror.ift  for  tost. 
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4.  Multiplex  data  buses. 

All  coiiimuiieat  ion  between  the  varimis  I'MIX  l.KU's  (line  rei'laeeable 
luiits)  are  made  over  rediuul;uit  data  buses  usini;  time  division 
imiltiplex  teeluiinues.  Hie  data  rate  is  1 iiK'^al’it  (vr  second  usinj( 
a Minehester  11  t'onnat . 

5.  IVita  bus  teniiinat  ion. 

li.ieh  bMlIX  tenninal  interlaces  with  the  data  buses  throuv;b  a stub 
line  connected  to  a data  bus  teniiinat  ion. 

Mvles 


IMUX  operates  in  eitlier  the  I'l  iv.lit  nxHie  or  ground  iiK\ie.  In  (lie  I'l  ii;bt 
iiXHle,  tlie  t'MUX  c.irries  out  all  commaiivl  and  iiKMiitor  t'l met  ions  as  iiroi^ramiiK'd , 
but  (’irS  coniiiand  I'luict  ions  are  locked  out.  In  the  eroiuid  mode,  the  I'll'S 
command  intert.ice  is  enabled  and  the  PMUX  boxes  are  - iibiect  to  automat  ic 
sliutdowii  it'  an  overtemperature  condition  developes.  Ibis  I'eatuiv  was 
incol^H1rated  to  make  l-MUX  independent  of  aircrat't  coolinj',  restraints  durinr. 
y^roiuid  testiiii;.  Hie  i^round  iimde  is  interlocked  uitli  ueiebt  on-uluvls  sensors 
;ind  other  signals  to  insure  tliat  this  iiKwle  cannot  be  used  when  the  aircral't 
is  taxi  ini:  or  airborne. 


IV . 1-MIX  phon 


IMIX  I'ont'igurat  ion 

rhe  IXIIIX  coni  i. curat  ion  was  based  on  proi  idinr,  tin'  elivt  rical  h separate 
svstems  (left  section  and  a riebt  sect  ioni  operating,  independent  1 \ and 
asvnchronouslv  with  iVvltindiuicv  within  each  svstem.  la*,  h 'Section  uso''  reilundant 
data  buses  (primarv  and  secondarv)  and  each  IMIIX  l.RU  transmits  and  receiie-' 
data  over  both  buses. 

1 ach  of  the  data  buses  consists  of  a pair  ol  twisted  shieKUwl  wires, 
ninninc  the  lencth  of  the  aircraft,  tliroiicli  whicti  the  svstem  comi'onents  are 
interconnected.  I ach  I'NRIX  box  is  connected  to  the  main  data  Inis  cable-;  b\ 
a teniiinat  ion  line  stiil-'  (J  to  at'  feet  in  lencth)  and  a vlata  Inis  teniiinat  ion. 
file  dat.i  bus  teniiinat  ion  provivles  stub  isolation  so  tliat  a failure  ol  am 
stub  will  not  affect  the  transfer  ol  data  between  other  l-'oxes.  I'lie  IM'X 
remote  boxes  c-dher  and  transt'er  data  upon  lontrol  box  command,  lor  battle 
daiiiayte  surv  i vab  1 1 i t , t lie  two  primarx  vlata  buses  are  run  vKnvti  v'lU'  sivk'  v'f 
the  aifvratt  aiul  the  twix  sev-vxtivlarv  buses  are  run  vK'wn  the  iMlwu-  su'e. 


I'ho  ivtiKUt'  ti'niiinal  I'onriijiinit  ion  Invoiit  was  basoil  on  irn'otinj;  tho 
si>;nal  quant  it  v roqui  ivnit'nt  s in  oaoli  area  of  tho  aiivraft  so  as  to  miniiniro 
tho  intorfaoo  wirini^,  minimizo  tho  Jifforont  typos  ol'  IRU's  roquiioii,  aiul  to 
iiui\imi;o  tl»o  sui'vivat'i  I i‘v  of  tho  systcNii.  llio  oonf  i.yurat  ion  lavout  lor 
Aiivr.kft  I (soo  fi.y.  11  iuo\  iJos  roim'to  tonninals  Jist  riliutoJ  from  tlio  fon\ai\l 
avionios  hav  to  tho  aft  avionios  hay.  flio  oapal'ility  oxists  for  I'HX  Ki\os 
to  Iv  a lilou  ii\  tho  \%oa|H'n  havs  on  SkVMmissilo  ixUai'v  laiuiohors. 

lour  tvpos  of  roiiK>to  torminals  woro  proviilovl  to  intorfaoo  with  tlio 
.liivraft  suhsvstoms.  I'hoso  tonninals  primarilv  diffor  in  tho  mix  ol  ininit  ' 
output  siqnal  ooiui  i t ion  ino.  whioli  is  proviiloJ.  flio  disoroto  tonninals 
ldosi,ynatod  I'S- 1 , PS  and  PS  51  o;m  onlv  handlo  disoioto  on-off  or  opon 
oloso  siitnals.  Pisoroto  signals  woro  staiulardi  .:od  as  5 volt  input  'out  jHit  s 
or  as  s\\itoh  olosuiv  inputs.  I'ho  disorott'  vliyital  (PPI  tonninals  o.in  handlo 
sorial  digital  signals  in  advlition  tv>  tho  disorotos.  I'ho  l'MP\  oonfijtur.it  ion 
for  tho  \iunhor  4 B-1  airoraft  is  tahulatod  in  fiyuro  J. 

I’ho  uso  of  rodundant  I’ontrol  hoxos,  (bus  oontrollorsl  was  solootovl  rathoi' 
th.ui  providing  roluiul.inov  within  a sinylo  I'ontrol  bo\  I'ho  I'ontrol  hoxos 
woro  x'ontrallv  looatixl  in  tho  (.'ontral  Avionios  Kiv.  I aoh  Control  box  has  two 
indopondont  iHiwor  supplios  which  .iro  orM  toyothor  on  tho  Uxul  sido.  I .loh 
jx'wor  supplv  roooivos  powor  fixnn  a difforont  souivo.  lor  battlo  d;uiuiv',o 
surv  ivab  i 1 i t V , ono  Control  box  of  oaoh  soot  ion  was  Kv.itod  on  tho  oppv'sito 
sivio  of  tho  airoraft. 

A sinylo  I'll'S  Intorfaoo  (I'll  tonninal  was  pix'vidod  in  o.ioh  I '1li\  soot  ion 
to  provide  intorfaoos  with  t'l  l'S  for  that  soot  ion.  Sinoo  I’l  IS  is  not  .i  mission 
orit ioal  svstom,  tho  I'l  doos  not  oontain  anv  rodundanov  oxoopt  tor  tho 
oapabilitv  to  'ransmit  and  roooivo  ovor  both  d.it.i  buses. 


V.  SY.Sn.M  CPI  KM'ION 

I'ho  lAIPX  svstom  siunplos  olootrioal  siynals  duriny  oaoh  t inx'  t ixuih' 
(nominal  Iv  approximatol  v 5J  mi  1 1 isooondsi  and  assiyns  o.ioh  siynal  to  .i  time 
slot  (binary  bit1  within  that  time  frank'.  All  of  tho  sampled  siyn.ils  .iro 
then  foniioii  into  a stream  of  Jl  bit  woixls  and  t r.insforrovi  ovor  (ho  data  link 
at  tho  rate  of  1 nvyabit  per  second.  This  rate  pomits,  in  oaoh  t ink'  frank', 
tnuisfor  of  all  present  b 1 data  siynals  and  burden  siynals  isiynals  roviuirovl 
for  traffic  x'ontrol  ;uk1  self  tosti  plus  rosorvo  oap.ioitv  for  svstom  ytx'wth. 
rhis  allows  all  I'MIX  inputs  aiul  outi'uts  to  bo  ui'datod  api'rox im.it olv,  51  (ink's 
per  second  (the  fr.um'  rato1. 
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FIGURE  2.  EMJX  CONFIGURATIOf^  SUrWRY 
M AIRCRAFT  m.  A 


The  I'.NRIX  system  oj^cratcs  as  a coimnajid- response  system  in  a fixed  frame 
mode,  liaeh  of  IXS  and  Hli  boxes  is  commanded  in  se(|uencc  bv  the  Control  box 
to  tnmsmit  all  stored  discrete  data  to  the  Control  box.  Hie  addressed  box 
then  trajismits  a response  woj'd,  followed  by  a continuous  sequence  of  data 
words,  luitil  all  of  the  input  discrete  data  has  been  transmitted.  Hie  Control 
box  tlien  addresses  the  next  box,  ;uid  the  tiamsmission  sequence  is  repeated 
by  that  box.  lliis  process  is  continued  until  the  Control  box  has  received 
all  the  discrete  data.  After  all  discrete  data  has  been  received,  logic 
processing  begins.  Ihe  Boole;m  Processor  steps  sequentially  through  the 
instructions  stored  in  its  programmable  read  only  memory’  (PUOM),  reading 
each  one  in  tum  ;md  perfonr.ing  each  ojieration  specified.  Using  the  address 
jx)rtion  of  the  instinct  ion,  the  I’rocessor  interrogates  the  input  memory 
to  obtain  the  variable  (single  bitl  stored  at  the  bit  location  associated 
with  the  instinct  ion  address.  Simultaneously,  the  Processor  reads  the  0!' 
code  portion  of  the  instinct  ion  and  configures  its  logic  accordingly.  Ilie 
input  variable  obtained  from  input  memoiy  is  then  processed  b\'  the  logic 
and  the  result  is  stored  in  one  of  two  accimnilators . The  next  instruction 
is  then  read  to  obtain  the  next  input  variable.  It  is  processed  and  combined 
with  the  previous  variable.  The  result  is  stored  in  the  accumulator,  replacing 
the  previous  result,  lliis  process  continues  until  an  instinct  ion- is  read 
that  identifies  it  as  the  last  instniction  for  a particular  equation.  At 
this  time,  the  result  stored  in  the  accumulator  (the  final  solution  to  the 
e<{uation),  is  tninsferred  to  the  (Control  box  output  rnemorv'.  After  all 
equations  liave  been  solved  and  all  solutions  are  stored  in  the  Control  box 
output  memon',  all  results  are  transmitted  to  the  appropriate  remote  teminals. 
All  equations  are  processed  each  frame. 

^lyiaj^  nigital  Data  Transfer 

ITie  nn  t>qie  boxes  perfonii  the  siune  functions  as  the  IIS  boxes,  but  they 
also  have  the  added  capability  of  accepting  serial  digital  signals  from  the 
aircraft  systems.  ITiese  digital  signals  must  be  in  a 17-bit  per-word  retuin- 
to-zero  (RZ)  format.  The  digital  words  may  be  either  aiicraft  generated  serial 
digital  signals  that  will  be  tnmsferred  through  IMIX  to  miother  part  of  the 
aircraft  system,  or  they  may  he  "packed"  discretes  (discrete  sigiials  fonmitted 
into  serial  digital  words  by  aircraft  system  interface  luiits). 

In  parallel  with  the  discrete  logic  processing,  the  Control  box  addresses 
the  nn  boxes  requesting  that  each  box  tninsmit  its  digital  data  to  the  Control 
box.  P.ach  nn  box  sequences  through  its  digital  data  input  channels  and 
transmits  the  data  without  buffering  in  continuous  digital  words,  until  all 
digital  data  have  been  tran.smitted.  The  serial  digital  words  arc  stored  in 
a memory'  in  the  Control  boxes,  and  retransmitted  to  the  proper  nn  boxes  within 
the  s;ime  frame  time. 
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The  Control  boxes  have  the  capability  to  reformat  any  packed  discrete 
words  received  into  single  discrete  signals  or  vice  versa. 

IMIX  Self -Test 

The  RMTX  makes  extensive  use  of  built- in-test  (BIT)  or  self  test.  Each 
remote  box  performs  self-test  in  its  own  operation,  can  initiate  a transfer 
to  its  redundant  electronic  circuits,  and  the  status  of  the  box  is  sent  to 
the  Control  boxes  in  a response  word  (BIT  status  word)  which  is  part  of  the 
input  message  to  the  Control  box.  The  contents  of  the  response  word  is 
monitored  by  CITS  via  the  storage  of  all  data  link  data  transmissions  in  the 
Cl  box  memory.  The  Control  boxes  can  command  the  remote  boxes  to  switch 
to  their  redundant  electronic  circuits  based  on  lack  of  response  or  upon 
receipt  of  improper  transmissions  from  the  remote  boxes. 

In  each  EMUX  section,  one  of  two  redundant  Control  boxes  assumes  active 
control.  The  standby  box  continually  verifies  that  the  active  box  is  issuing 
the  correct  outputs.  If  the  number  of  disagreements  between  the  two  boxes 
exceeds  15  for  two  consecutive  frames,  the  standby  or  off-line  bcx  requests 
an  off-line  test.  During  the  off-line  test,  both  boxes  run  a diagnostic 
tost  of  their  respective  Read/Write  memory.  If  the  primary  or  on-line  box 
passes  the  test,  it  will  continue  as  the  on-line  box.  If  it  fails  the  test, 
it  will  remain  "off-line"  and  the  standby  box  will  assume  control.  This 
"off-line"  check  requires  only  about  100  milliseconds  and  is  performed  no 
more  frequently  than  once  per  minute. 

In  addition,  each  Control  box  performs  various  self-tests  of  its  own 
internal  functions  throughout  each  fraine. 

Operation  of  IMDC  is  illustrated  by  a typical  application  as  shown 
in  figure  3 wherein  the  pilots  can  control  the  alternate  throttle  actuator. 

In  this  case,  EJ-HX  is  a back-up  to  the  hardwired  system.  'Flie  Eltt/X  DS  box 
senses  the  throttle  jog  switch  actuation,  the  signals  are  relayed  to  the 
Control  box,  the  Control  box  sends  the  appropriate  commands  to  another  PS 
box  which  controls  power  to  the  alternate  throttle  motors.  The  Control 
box  develops  the  appropriate  commands  depending  upon  the  instructions  as 
programmed  for  the  Boolean  processor  in  the  Control  box. 

The  details  of  the  electrical  interfaces  for  the  electro -mechanical 
control  of  power  is  illustrated  in  figure  4.  The  liNlUX  remote  box  outputs 
a 5 volt  conmand  to  a solid  state  relay  driver.  The  relay  driver  controls 
the  230  volt  AC,  400  hz  power  to  the  relay  coil.  The  EMUX  remote  box 
monitors  the  status  of  the  circuit  breaker  and  the  relay  contacts.  This 
information  is  used  in  the  Control  box  in  the  processing  and  interlocking 
of  power  controller  commands.  The  power  controller  status  can  be  monitored 
by  AGE  during  ground  operations  and  by  CITS. 
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DATA  acquisition 


FIGURE  3.  TYPICAL  APPLICATION  0^ 


FIOJFE  i).  ENK  INTEPFWI  WITH  ELECTRWEOWIICAL  POCP  CTfl 


IMojjnuimtij; 

To  enable  the  IMIX  to  pixipeiiy  carry  out  the  requiiwl  loj>ic  and  ixiwei- 
control  function'^,  the  control  iik'iikiit  in  the  (xMitrol  box  must  he  projtrammeJ 
usin^  appropriate  software.  Tho  I'-ontrol  box  sequentially  reads  instructions 
stored  in  its  control  meiiK)ry  and  sequentially  perfonns  the  fiuictions  defined 
in  each  instruction.  Simnly  stated,  it  reads  an  instruction,  perfonns  the 
fiuiction,  ;md  tl\en  reads  the  next  instruction.  The  control  imnnory  is  a 
pro.yi';uiinahle  read  only  meiiKiry  ll’llllM). 

I'he  PROM,  when  ju-operly  progr;uimK\l,  contains  the  fol  lowing  inumiiat  ion: 

A.  Sequence  Control  This  infonnation  defines  the  sequences  in  which 
the  Oontrol  box  is  to  collect  and  tixuismit  discrete  and  sei'ial 
diktital  data,  perfonns  self-test,  starts  and  stops  processing,  and 
resixmds  to  executive  or  exteriril  subroutine  coninands.  In  addition, 
it  contains  serial  digital  rout  injt  instructions. 

R.  I’l'ocess  int:  I'hese  instructions  define  the  fiuictions  required  to 

solve  all  boolean  and  lime  IVlay  equations,  the  sequence  of 
solutions,  and  the  meimirv  location  of  input  and  output  siy.nals. 

C.  l,oad  MniaiteiJK'nt  - These  instructions  define  the  load  Minayomont 
rout ines. 

I'he  i';  jiliys  ica  I l\’  programmed  by  external  AiT.  dp  to  ll,J('I  twi'iiti 

one  bit  words  must  be  |irov;ramiiK\l  into  the  PROM.  Obvioush’,  an\  manual 
proyramminj;  method  would  involve  many  man  hours  and  would  be  subject  to  a 
considerable  dovtree  of  error.  To  accoiiuuodate  economic  and  proficient 
pro,qr;uiiminit,  an  automatic  ilevice  teniied  the  "Mi'iikui  l.oadei'  Wrifier"  is 

utilii’eil.  This  ilevice  is  capable  of  accept  ini;  proy.rammini;  inform.it  ion  stored 

on  t.ipe,  ,ind  usiny,  this  infonnation,  rapidlv  luoyrams  each  PROM  card.  In 
.iddition,  it  is  cap.ible  of  test  iiu;  the  PROM  to  verifi  its  programmed  content. 

I'he  Mo'iKirv  l.oader  Verifier  requires  input  data  stored  on  tape.  Ihis 

t.ipe  is  prep.ired  usiny  .in  IbM  .xO('  Compiler  Proyram.  I'he  tnmpiler  Proyram 
.iccepts  raw  data  decks  .and  transposes  this  data  into  a set  of  machine 
l.inyuay,e  instructions,  stored  on  tape,  to  be  used  bv  the  Mimiorv  loader 
Verifier  to  phvsic.illv  proyram  the  Control  box  PRiiM  cards.  Ihe  Compiler 
Pioyr.im  is  I KM  And  compatible  .and  is  written  in  fortran  IV  lanyuayc. 
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I .oaJ  M;mat;oiiient 

Load  in;uiagement  is  a fiuiction  of  tho  (bntrol  box  whioh  nxidifies  tho 
normal  control  of  the  elcetrical  loads  (thmiijjh  [xwer  eontixil lers)  as  a 
fiuKt  ion  of  aircraft  conf  ijjiirat  ion  ;md  operational  iikhIc.  'Hus  fiuiction  of 
the  Control  Ikix  protects  the  priftvirv  power  j’eneraf  ion  system  from  becoming; 
overloaded  in  the  event  of  a multiple  electrical  senenitor  failure,  so  that 
loads  will  be  maintained  within  the  jjenerator  and  aircraft  cool  inj;  system 
capacity.  l,oad  imuKJj^eim'nt  is  also  used  ilurin,k:  .yrmnid  operations,  to  assist 
in  confijjurinn  the  aircraft  durinj;  test.  Load  m;uia);eiiK'nt  is  accomplished 
automatically  by  inhibiting;  or  jxiwerini;  down  api>licable  aircraft  systems 
;uid/or  et|uipnx'nt  as  dictated  by  a predetennined  schedule  for  a particular 
loail  m.ijiaj;ement  nxide. 

rhe  ixxitnil  boxes  receive  ;uk1  store  appropriate  discrete  priority 
reference  signals  provided  by  various  svstems.  (x'nerator  load  contractor, 
bus  tie  contractoi',  auxiliaiy  power  luiit  (APII) , ;md  en.yine  status  .ire 
tyincal  ex;unples  of  priority’  reference  signals.  Using  the  in'iority  reference 
signals,  the  Control  boxes  in  each  I'MIX  section  logically  select  one  of  twelve 
av.i liable  load  iminagement  schedules  stored  in  eacli  Control  box  memoi'y.  l.ach 
schedule  consists  of  power  control  priority  bits  (ones  or  zems")  in  a 
read-only  memory  (ll(l^').  The  hits  enable  or  disal'le  t’w  o?x'ra(  ion  of  "JO 
ixiwer  controllers  in  eacli  LMIIX  section.  The  Control  boxes  output  conunands 
to  ixiwer  controllers  as  recpiired  to  itihibit  or  |H>wer  down  aj^plii'able  systems 
;md/or  equi|)mt'nt.  The  following  lo.id  m.'in.igem('nt  modes  .ire  provideil; 

Re  fue  1 /IX'  fue  1 

The  I'e fue  1 /do fue  1 imxle  (mode  1)  provides  limited  electrical  ix>wer  and 
is  used  during  grouiul  refueling  and  defuel ing  and  during  other  compatible 
limite<.l  lo.id  functions  on  the  gromul. 

Alej't  Mixle 

In  the  alert  iiKxle  (mode  Jl  , both  Al'U's  are  operating  and  bled  and  at 
le.ist  two  generators  (one  driven  liy  each  Al'U)  are  on  the  line,  llect  rival 
power  for  alert  equipment  is  limited  to  about  U>  kva  and  reduced  to 
about  M kva  during  a four-engine  start.  Tlie  rcvluct  ion  in  ixxver  is 
required  for  simultiuieous  four-engine  start  without  exceeding  the  ixiwer 
capability  of  the  Al'U's. 
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(iiio-r.n^ino-nri  von  t'ic'noiatm-  Nkxlo 

Tlio  ono  on^iiio-iirivon  v^onorntor  iikuIo  (iikvIo  3)  |no\  iJos  pouor  I\m'  KvuI'' 
iviiuirod  to  nuiintain  a sat'o  aircraft  with  mission  strike  cai'ahilitv 
when  onlv  one  of  throe  oiu'. ino-Jii von  ,i;onorators  ronains  on  lino. 

All-Up  Mode 

I'ho  all-up  or  nonnal  iikhIo  (irntdo  11  luxnidos  powoi'  for  all  elect  lical 
loads  on  the  aircraft.  I'his  mkhIo  is  onahk\!  autoiiwit  ical  1\  if  no  otlior 
iikhIo  is  enabled.  Mien  airborne,  iiMde  I requires  at  least  two  enr.ine 
driven  jjenerators  to  be  on  the  line.  I'his  is  the  nonnal  fl  ivdit  iikhIo 
wherein  all  loads  are  supiU  ied  with  power  on  demand. 

All  IJji  Nkiintenance  (UllS)  Miul_e 

fhe  all-up  maintenance  (t'll'SI  mixle  (mode  .11  is  enabled  when  the  I'.MIV/ 
t’lrs  j;roiuul  maintenance  interface  has  been  enaliled.  fhere  are  no  specil  ic 
[Kiwer  supply  requ i reiiK'nt  s for  this  imide.  1 xternal  iiowei-  or  anv 
coml'inat  ion  of  i;enerators  (en.yine  luunber  or  Al'U  driveni  can  l>e  utilired. 

In  this  mode,  I'lf.S  contmls  the  total  load  so  .is  to  limit  the  load  to 
be  within  the  jiower  source  capability. 

Proximity  .Switch  lest  Mode 

In  this  imxle,  t'll'.S  can  perfonn  tests  of  proximitv  switches  with  all 
systems  and  equipnK'nt  ixiwered  dowii  except  the  pro'  .mi tv  switch 
electronics  luiits,  id'f.S,  ;uk1  the  aircr.ift  env  i I'onmental  cool  iny 
syst  em. 

tlniund  Operat  iiij’  Mode 

The  yroiuid  ojierations  iiKide  (iiKxle  81  (irovides  an  override  of  the 
autonvitic  load  manayement  iikhIo  selection  and  is  renuired  for  i'ost 
fliyht  drift  testiny  of  the  Inertial  NV'asurement  Unit  ( IMU1 , and  to 


simplify  the  ptxicedure  for  t ransit  ioniny  from  yrouiul  cool  iny  to 
intental  cool  iny  of  euuipiiK'nt  bavs. 


\ I . SYSTiM  j]!,! i.os(ii’iiv  JvJ  Qii!j<];^ii:vrs 

Tlio  H I IIMIIX  systom  vli'sij;ii  is  l^jisoil  on  usini;  a saniploil  ilata  mult  ipli'x 
control  svstom  to  proviJo  tho  oonfixil  of  as  manv  aitvraCt  fuiK-t  ions  as 
ixissihlo  within  tho  followinit  const  raints. 

I.  Sat'oty  of  I'l  iyht  Ciuiot  ions  shall  ho  iiarJv^iroJ  lU'  Ix'  pixn  iJoi.1 
with  a liai'ilwiioJ  or  olooti'o  iiKxhanioal  haokuji  if  mul  t iploxoil . 

J.  Iho  uso  of  mult  ij'loxini:  will  roJuoo  wiriny  or  is  I'oquirod  to 
proviilo  tho  nooossary  control  loyic. 

Tho  systom  jihilosophy  was  that  TMdX  was  ossontial  to  mission  succoss 
hut  tho  airci-alt  couKI  ho  I'loiUi  aiul  roturnoJ  to  haso  if  IMUX  sufTorixl  a 
major  or  comjiloto  Tailuro.  Sinco  TYIHX  was  ono  of  tho  first  oxtonsi\o  usos 
ol  mult  iploxiny,  tho  Jocisions  to  mult  iplox  or  haixlwiio  locoivovl  much 
attention  as  thoro  woro  rosorvat ions  about  usiny  such  a now  sxstom,  Tho 
t'ustomor  (H.S.  Air  Torco)  foniKxl  a roviow  panol  to  ovaluato  tho  ovorall 
mix  of  haixlwiro  aixl  multiplox.  'Hio  chart  shown  in  fiyuro  S is  roprosonta!  i\o 
ol  tho  mix  of  control  tochniquos  that  was  achieved.  As  shown,  thoro  wore 
definite  reasons  whv  tho  uso  of  mult iploxiny  was  not  used  for  contixil  of 
certain  lunctions.  In  yonoral  , all  aircraft  fuiutions  woro  multiplexed 
except  for  tho  folhxxiny; 

I.  Short  wire  runs  aixl  whoioin  lkx>lo;ui  loyic  control  oixuat  ions 
wore  not  required. 

J.  Analoy  or  servo  txqx'  siynals  (tho  numhor  of  siynals  to  ho  handled 
did  not  Justify  tho  result  iny  woiyht  and  comploxitx  pt'iialtios  in 
TMIX). 

3.  Siynals  required  when  T.MUX  would  ho  inoperative  (pro  start  up). 

•1.  hack-up  or  omoryoncy  functions  for  safotv  of  fliyht. 

.3.  Critical  nuclear  or  conventional  weapon  siynals. 

The  yonoral  approach  was  to  uso  TMIIX  as  much  as  possible  and  in  tho  nx\st 
cost  effective  manner.  Tvon  whore  siynal  traffic  was  localized,  TMIX  was 
used  when  tho  loyic  process iny  capabilities  and  rodiukhmcy  was  required  or 
when  tho  Central  Inteyrated  Tost  System  (CTl'S)  required  access  to' the  data 
via  IMIX.  TMIX  is  luiitiue  relative  to  other  on  Ixtard  systems  inchuliny  CITS 
in  that  electrical  switch  closuix's  (open  or  closed)  can  he  sensed  as  a source 
of  data. 
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Reilimd;uK'v 


Hie  liMPK  system  is  capable  of  meeting  the  subsystem  reliability 
requirements  throu>;h  the  use  of  two  indcivndent  IMIX  sections  (systems), 
the  use  of  rediuidant  data  buses,  the  use  of  rediukUmt  electronics  in  each  of  tlie 
I^IIX  remote  Ixixes,  ;uid  the  use  of  reviiuid;uit  input/output  chimnels  to  interface 
with  subsystems  or  (xiwer  contixil  lers. 

llie  subsystem  desiyn  eiyyineer  had  nviny  oi’tions  to  choose  from  ;uui  could 
establish  the  degree  of  rediuuhuicy  provided  for  any  given  reviui leiiK'nt . In 
addition,  the  I'MIX  software  provided  the  use  of  IVxiIean  processing  vdicrein 
the  ptxtbabi 1 ity  of  false  operation  could  be  minimised  by  the  use  of  voting 
logic  or  other  logical  permutations  as  a safeguard. 

bach  IMIX  section  uses  two  data  buses  for  tr;msmission  and  reception 
of  data,  bach  bXlIX  I,RU  tnmsmits  and  receives  data  over  both  buses,  but  the 
data  used  from  either  bus  is  selected  after  validity,  s>i\c,  parity,  and 
fonnat  checks. 

liach  liMlX  reiiKite  tenninal  is  provided  with  fully  rediuidant  electronics 
except  for  the  input  and  outinit  buffers  which  are  conrxui  to  both  electronic 
blocks.  The  IMIX  Ixtx  will  shift  to  the  rediuidant  block  of  circuits  as  a 
result  of  ;ui  intenial  self-test  deteminat ion  of  uixm  command  b\  the  lontrol 
Ix-ixs.  bigure  (i  is  a diagnun  of  the  rediuulancy  of  a tvjiical  reiiKite  tenninal. 
bach  remote  lxix  receives  two  independent  sources  of  power  and  incoi'jxuat es 
two  jxiwer  supplies,  line  jxiwer  supply  is  dedicated  to  the  primary  block  ;md 
the  other  to  the  secondary  block. 

Rediuidancv  was  provided  for  subsystem  interfaces,  when  reouired,  b\  using 
IXIIX  inputs  and  outputs  from  different  l^VX  boxes.  Wien  rediuidant  power 
control  was  required,  various  configurations  of  parallel  and  series  relav 
drivers  were  used  to  protect  against  power  "fail  on"  or  "fail  off." 

fault  loltunmt  Concepts 


riie  aircraft  was  made  fault  tolenmt  to  IMIX  failures  by  the  use  of  the 
f o 1 1 ow i ng  t ec  Im  i que  s . 

1.  Use  of  lx>th  IMIX  sections. 

.•\n  example  is  the  weiqxm  bay  vloors.  If  the  left  IMl'X  iloes  not 
carry  out  the  door  commends,  the  alteniate  door  system  is  operated 
by  right  IMIX. 
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FIGURE  6.  EMJX  lODTE  TERMINAL  ELECTRONIC  CIRCUIT 


2.  Use  of  Jifferent  1M)\  boxes. 

IHuil  inputs  ot  coiiitKUuls  onn  bo  rooted  tbrou^^li  different  boxes 
makinv’  a jtiven  set  of  inputs  and  oof  [nits  iitiiiiuie  to  ;i  box  failure. 

Use  of  software  "l\unp-Up"  or  time  delays. 

lAiniinands  can  be  protected  ajiainst  mt.'nH.'ntary  "drop-outs"  by  suitable 
logic  processing  in  the  Control  boxes.  I'he  commands  can  be  lieKl 
luitil  a given  inuiiber  of  input  simiples  are  zeroed  oi‘  a slow  to 
release  time  dela\'  fiuiction  can  be  progr;mmied  to  bridge  across 
iiKmK'ntary  losses  of  data. 

4.  Use  of  fail-safe  iiKxies. 

I'he  IMIX  boxes  are  designed  to  fail  to  the  "off"  state  or  shut 
dow7i.  fherefore,  the  aircraft  subsystems  are  designed  to  accoinnodate 
a fail  off  coTulition.  I’ertain  critical  jxiwei'  circuits  use  noniiallv  - 
closed  relays  such  that  a "fail  off"  will  not  interruiU  ixxver. 

5.  Switching  to  rediuxlant  circuit  blocks. 

The  bui It- in-test  circuitrv  in  tbe  l.MU\  remote  boxes  will  cause 
the  boxes  to  switch  to  the  altei'nate  block  of  electmucs  wlu'n 
a failure  is  detected  in  the  initially  operating  block.  If  a 
failure  is  subsetiuent  ly  lietected  in  the  alternate  block,  the  box 
shut  • '.own. 

.Sui'vj  vab  i I i t^' V^l  ae  rab  i 1 ft y 

I'he  CMIX  system  is  hardened  against  the  radiation  and  elect  in  magnetic 
effects  of  a nuclear  event.  I'he  CMUX  Control  box  operation  mav  be  mmientar  i h 
interrupted  by  the  event  but  the  reiiKite  boxes  will  hold  their  previous  state 
outputs  for  2 .seconds.  Since  the  bo.xes  are  designed  to  not  be  damaged  bv 
luMr/'fRi'b,  the  system  will  resuiiK'  operation  after  the  event. 

I1ie  layout  of  the  Ixixes  and  data  buses  was  based  on  minimi r.ing  IMUX 
susceptibility  to  battle  d;uiuige.  I'he  two  orimaiv  data  buses  ( fi>r  both 
.sections')  are  routed  down  the  left  side  of  the  aircraft  and  the  two  sect'udarv 
data  bu.ses  are  routed  down  the  right  side  of  the  aiivraft.  Ihe  two  ('ivitiol 
bo^'s  for  each  IMIX  section  are  dejiloyed  so  as  to  minimize  tbe  inobabi  1 i tv 
that  Ivoth  would  Ix'  ikimageii.  llie  ORIX  ilata  buses  are  piotected  against  shoits 
on  the  stub  lines  to  the  bMUX  boxes  bv  transfonner  resistor  network  ter 
minations.  Inch  IMIX  data  bus  c;ui  tolor;ite  up  to  <ive  shorted  stub  tines 
without  suffering  excessive  degravlat  ion  of  the  signal. 
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Ml]^-_Srn- 1 SS3  ibi  1 ity 


Tho  1MI\  svsteiii  vv;is  coiweivovl  in  the  time  period  prior  to  the 

issiumee  of  any  niilitaiv  st;uKlai\l  for  aireraft  multiplexing.  However,  tiie 

system  influeneed  the  eontent  of  Mll.-STH- 1 (\ircra*'t  Intenial  lime 
Pivision,  Multiplex  Pata  Pus  System)  as  was  initially  released  in  Auvtust 
IP'.X.  I nyineers  assoeiated  with  t-'IHV  sei’ved  on  the  Siviety  of  Automat  ive 
l-n^ineers  (SAD  Sulvoiimi i ( t ee  A-JK  whieh  assistevl  the  Air  I'oree  in  foniiulat  iny 
MU.  SIP- 1 .''S.X.  As  a result,  tlie  I'MPX  svstem  is  larjtely  in  agreement  with  the 
MII.-STP  iviafixe  to  transmission  hit  rate,  si.yn.il  foniiats,  eleetrieal 
eharaeter ist  ies  and  eonmiand  resixnjse  pi'otoeol.  I'he  lAllIX  is  not  eompatible 
with  N'M.-.STll  IS.SS  in  that  lARlX  uses  JJ  bit  words  versus  J()  bit  words  for 
1SS5,  and  the  eoimiiand/status  words  utilise  a sliehtly  different  word  foniuit  . 
,MlI.-S'fP  IS.S.X  revision  "IV'  (seiieduievi  for  release  in  Ui-S)  allows  eertain 
iiKU-e  sophist  ieated  modes  of  operation  sueh  as  the  s i mu  1 1 ;uh'ous  broadcast 
to  all  reiiKMe  tenninals.  Ihe  revised  MII.-.STP  gives  the  svstem  designer 
considerable  latitude  in  meeting  a svstem  requirement  but  does  standardi::e 
on  data  bus  characteristics,  transmission  fonnats,  protocol,  iixuie  codes, 
status  codes,  and  electrical  interfaces.  I'ompl  i;uice  with  the  standard  mav 
not  result  in  interchangealile  hardwaie  Init  should  maximize  inter-operabi  1 it\'. 

1 n t e r face  t'omj>at  i b i 1 i t %■ 

line  of  the  significant  factors  which  cont  r ilnited  to  the  successful 
integration  of  liMHX  on  the  H- 1 was  stand;ird  i rat  ion  of  interface  signals  wiiich 
in  tuni  resulted  in  interface  compatibility.  .Vn  internal  Rockwell  International 
(Ril  engineering  specification  was  written  which  piovided  the  electrical 
parameters  for  discrete  and  serial  digital  signals  and  signal  conditioners. 
nUs  dociDiient  control  leil  voltage  levels,  signal  fonnats,  timing  logic  level, 
etc.  I'his  specification  was  invoked  on  practical  h'  all  sui^ipl  iers  of  b.ardware 
for  the  various  subsystems  and  was  adhered  to  bv  lyRlX  and  t'l  rS.  ,\s  a result  , 
the  mmiber  of  interface  problems  were  minimired. 

I'he  compatibility  between  liMHX  and  the  equipment  supplied  by  tlie 
associate  contractors  for  the  offensive  .ind  d''fensi\e  avionics  was  assured 
by  specifying  in  detail  the  interface  parameters  in  the  avionics  interface 
control  dociDiients  (lUPl.  In  addition,  tests  were  conducted  in  Ikx'ing's 
System  IVvelopment  haboratoiy  (SPl  1 wherein  a partial  liMlIX  systcmi  (t'ontrol 
1k)X  and  twxi  renKife  Ixi.xesl  were  intcygrated  with  Itoeing's  Interface  .Adapter 
Units  ll.Xin  ;uicl  other  avionics  controls.  I'his  testing  assuivd  that  tb.e  two 
asNTichronous  multiplex  systc'ins  (I'MPX  ;uk1  .\.\R1X1  could  reliable  coimmin icate 
with  each  other. 
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IMIX  was  appliod  so  oxtensiwly  throui^liout  the  'M  that  practical  Iv  all 
aircraft  systems  were  intojtrated  with  IMIX.  I'ijture  "■  contains  a list  of  the 
systems  ;uKi  the  functions  associated  with  those  systems  that  were  li;uulled  hv 
IMlX. 


.^yionics  Power  Control  ;md  Stores  M;inai;enK'nt 

cine  of  the  TOre  extensive  applications  of  I'MIX  is  involved  in  the  control 
aiui  statusinj;  of  all  electrical  powei'  to  the  offensive  and  defensive  avionics 
tojtether  with  stores  iiumaitement . fhe  IXIHX  interfaces  witli  tlie  Avionics 
t'ontrol  Unit  lAHI)  complex  via  serial  di.yital  interfaces  with  A'lUX.  (See 
t ijjui'e  8.1  The  control  ;md  stati'.s  ti'affic  between  the  two  multiplex  systems 
is  Inmdled  over  two-way  serial -digital  traffic  Ivtween  the  two  multiplex 
systems  is  haiulkxi  over  two-way  sei'ial -(.ligital  clnuinels  between  the  avionics 
Interface  Adapter  Unit  (lAUl  :md  an  IMIX  remote  tenninal  (UU  hox1 . I’he  two 
way  clrmnels  are  I'ediuuhmt  ;uk1  cross-st rapped  for  reliability.  The  power 
control  conimuuis  are  "packed  discretes"  in  that  each  IP  hits  jilus  parit)  word 
contains  IP  different  (.iiscrete  on-off  commands  or  gi'oups  of  liits  as  used  to 
control  weapon  hay  door  position  or  rotarv  launclier  jutsit  ioning.  In  turn, 
tlie  status  of  power  to  the  avionics  and  weapon  stores  together  with  weapons 
bav  door  and  rotary  laiuicher  position  is  transmitted  to  the  AfU  via  T.MUX  and 
/\MUX.  The  end  result  is  that  tlie  U'eaix'in  IVliveie  AiH,  tiuidance  Navigation 
ACU,  ;md  tlie  IX'fensive  AlTI  c;ui  contml  power  to  the  avionics  boxes,  SRAM 
missiles,  IXiM  equipment  and  facilate  tlie  launch  of  the  missiles  through 
control  of  launcher  rotation  and  weapon  bav  doors. 


Vlll.  lUrURT  lMPRO\T.Mi;N'rS  WU  INNOVATIONS 


As  a pioneer  system  in  the  art  of  aircraft  multiplex  control  and  data 
transfer,  IMIX  was  very  successful  and  cost  effective.  However,  a second 
generation  design  was  planned  for  implementation  on  the  Production  T-1  Prog  nun 
prior  to  the  Presidential  decision  to  teniiinate  the  I'rogram.  The  primarv 
(lurixise  of  the  redesign  was  to  reduce  the  recurring  hardware  costs  bv  in- 
corixiration  of  various  electrical  and  mechanical  improvements.  Hie  major 
electrical  improvement  was  to  convert  the  main’  ty]ies  of  !'vl>rid  integrated 
circuits  to  monolithic  circuits  which  would  result  in  reduced  luiit  cost  and 
higher  reliability.  Additional  vohune  was  made  available  in  the  boxes  for 
the  ixiwer  supjilies  which  allowed  the  power  supiilies  to  be  repackaged  in  a more 
producible  and  economical  configuration.  Additional  instruction  memorv  was 
provided  lor  the  Uontrol  boxes  which  would  facilitate  future  growth  in  the 
use  of  lAIIX.  Miscel  laneo’us  chassis  improvements  were  made  such  as  using  cast  in 
instead  of  niichined  components  which  would  further  reduce  production  costs. 


AIM  INDUCTIOM  CONTROL 


CLECTRICAL  POWER  SUPPLY 


INSTRUMENTS 


* CMilrol 

•VpMi  ov«rridt 
Pfdbich  pofition  mdKMipt* 

MmmiN  commMidf  Mid  opirMNw 

MmhiN  conirol  MMti  ilMMt 

* * ■ * - - ^ ^ 

MDOv  WfvCV 

* IndiMltont  Mid  itatvi 

CM>t»on  lifhit 
Roiition  Midicatort 
Svttam  tta(y«  to  CITS 

* Indwt  poMtf 

AUTOMATIC  PLIGHT  CONTROL 

* Caution  lights 

* PoMf I control 

AUXILIARY  POWER 

* AccoMOfV  Wiva 

Oil  praiiura  and  tampafatura  ilatut 
Spa  ad  Mnamf 

* APU  itMt  accumulator  cliarfa  pump  motor 

* In  llifht  modat 

CENTRAL  INTEGRATED  TEST 

* Poarar  and  iifnal  control 
CREW  ACCOMMODATIONS 

* Efilry  ladder  indicatiom 
CREW  ESCAPE 

* Caution  and  MMmnp  liflitt 


* Caution  and  adaiaorv  lipliti 

* Powar  control  aaaamMNa  control  and  itatut 


ENGINES 

* Anti  ica 

* Fual  lAutoM 

* Initrvmanit 

* Normal  itart 

* Spaad  lockinf 

* Total  tamparatura 

* Thrutt  control  - altarnata  moda 

ENVIRONMENTAL  CONTROL 

* Avionict  apuipmant  coolinf  control 

* Coolinf  affact  of  datactor 

* Craw  compartmant  tamparatura  control 

* Enfina  Waad  loop  Nr  control 

* Pual  coolinf-loop  rarn-Nr  acoopa  and  Moioan 

* Liquid  coolani  pumpi 

* Wmdihiald  anti  ica  and  dafof 

* Wmddiiald  rMn  remoad 

* Windihitid  waah 

FLIGHT  CONTROLS 

* Caution  lifhti 

* Power  control 

* Trim 

* Position  indicators 
FUEL  SUPPLY 

* Aatial  ralutliftf 

* Ballait  tarsk  isolation 

* Fual  coolinf  loop  pump  arsd  croasoaar 

* Fuel  flow  indicatron  and  strstinf 

* Laatl  control  vaNas 

* Nitroftn  inartiisf  and  pcatsuritatron 

* Pumps  - Boost,  transfar.  arsd  sesaartfs 

HYDRAULIC  POWER  SUPPLY 

* Caution  lifht 

* Hydraulic  fluid  puentity  indiector  sNf-itst 


* Anti  ica  haatari  ~ pitol  stctic  end  totd 
tamparatura  ptobas  and  AOA  aanas 

* Cantrd  Mr  data  computar 

* Fliffit  director  computar 

* Flifhi  mstrurrsants  lifnd  conaartM 

* Gyro  siabilication  system 

* RGA/AOA/AVL  eompulcr 

* Horuontd  situation  indicator 

* Variicd  seda  indicator 

* Vertical  Ptuatron  draplay 

LANDING  GEAR 

* Normd  ratracdon  and  wtandaa 

* WMninf  and  dnwnloali 
Flosa  c^kaal  staarinf 

* AmnhM 

LIFE  SurrONT 

* Oiy«Mi  lew-»mMM 
LIGHTriQ 

* LoiMif  anri  landintAMt  lliltta 

* Mtion  liftiti 

* Anticen*uon  Hfhti 

* Awial  rtfiMlint  min$  intpaction  It^n 

MISSION  AND  TRAFFIC  CONTROL 

* Fowac  eontnH  and  cauHon  ll^n 
NAVIGATION  AND  WEAFON  DELIVERY 

* Emm  eonttol  and  caatlon  ll^ti 
STORES  MANAGEMENT 

* Rawar  aontiM  and  cartlwi  NShti 

* Waapon  inenWpalm.  atmlnp,  and  lalaaM 

* Mtoapon  kay  dppr  mpM 


FIGURE  7.  SYSTEMS  INTEGRATED  WITH  EMUX 


2-WAY  SERIAL  DIGITAL  CHANNEL  (TYPICAL  4 PLACES) 
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Si'l  ill  St  .It  r I’lnu'i  t out  rol 

rill'  lour  ro'-iM  nil  1^  1 .iiiiruit  U'-i\l  onl\  ol  oi  t ronioi  li.in  1 1 ,i  1 i ir.iiit 
I'lo.ikoi'-.  aiul  rol.U';,  howoroi  , t ho  IMUX  '-\‘-toiii  ii.o-  Jo'.  i r.iioil  to  ho  ir-ovl 
III  t iiii.it  ol  \ to  oont  rol  'ol  iil  --tiito  poiior  i out  rol  lor--,  lor  t ho  proiliu  t ion 
airor.itt,  t!io  Vitonotios  I'.roui'  ol  !;i  ilovolopoil  ,i  -ol  ul 

st.iti'  I'oiior  ,i--'’Oiiihl  \ (SSl'i'M  anJ  throo  t \ po--  o|  intorn.ii  oironit  movliilo--. 

I'ho  SSri'\  i'-  ilo'-ir.noil  to  ho  a lino  ropl.Ko.ihIo  unit  (ll.'li)  iihoro.i--  t ho  mtoin.il 
moiliilo  . uill  ho  shop  ro|'l.ii  oahlo  unit--  tSKlI'--).  lirairo  " i 1 hr-t  r.it  o--  t ho 
I'l.iniioil  oonT  ii’.iirat  ion  ol  t lio  SS1\'\. 

I'ho  pouor  oontrol  nioiliilos  aro  printoil  oirouit  hoaiiN,  o.ioh  ol  \ihuh 
oont.iin-.  lour  pouor  oontrol  i iroiiits.  I'ho  ol  hor  t\io  t\po'-  ol  iiio-.liil  o--  ,iro 
ho  St  at  IP- ' i sol  .It  ion  iiioiliilo  iisoil  to  pixniilo  i-.olatoil  st.ilir-  -- 1 ini.i  I . .iiul  1 ho 
loi^ii'  moiliilos  iisi'il  to  I'lin  iilo  "or"  ”aiul"  pat  uir,  ol  oomiii.iiul  --ir.n.il  --  to  I ho 
pouor  oontrol  moiliilos. 

Soliil  Stato  I’ouor  lonlrollor  i.SSl'Cl 

Iho  SSrr  I--  .1  pol.iri  .'Oil,  I'istahlo,  solid  sl.ilo  doviio  h.iv  inr,  .in  output 
oirouit  th.il  lan  ho  .k'lii.vtod  In  a lou  lo\ol  pol.iri  od  '-i)',n.il  to  Iho  input 
iirouil.  Iho  output  oirouit  prosont-  .i  hir.h  unpod. nu  o to  t ho  I lo\i  ol  iinront 
III  It'-  ''oil’''  or  trippi'd  ooiulition  .ind  loii  inipod.inoo  m it-  "on"  oondilion. 

Iho  priiiiarv  lunotions  ol  tho  SSl'i'  .iro  ill  to  pro\  ido  -i'  \ \i'.  h'l'  h 
olootriial  pouor  to  .i  spool  lio  airoralt  load  upon  roio’pl  ol  .i  S volt  IH 
oontrol  --ir.nal,  .iiul,  U'l  to  prov  ulo  ovorlo.id  prolovliMi  to  Iho  .liiii.ill  uiiinr, 
in  tho  ovoni  ol  an  ovoroiirront  -utu.it  ion  ro'-iillin)',  Iroin  .in  oloolrual  ovoilo.id. 
Sooond.irv  lunotions  aro  ill  to  prov  i do  --t.itu--  inlormat  ion  ol  iho  "tsi'd  to  I'H'N 
.ind,  l.'l  to  prov  ido  ovorlo.id  trip  in i onn.it  ion  to  IMIIX.  (Soo  lir.iiro  Id.l 

I'ho  oiirront  sonso  .nul  trip  t uni  nr.  oirouit  I nu  k--  Iho  load  oiirronl  In 
iiK'nitorinj;  tho  vollapo  drop  .loro---.  .i  I i vod  rosn-ior  in  --oi  io--  uith  tho  lo.id. 

It  prov  ido-.  trip  --ir.nal--  to  tho  oontrol  lor.io  hasod  on  I'rodot  onnuu-d  ourront 
vorsus  t iino  pi-ol  ilos.  Iho  voll.ir.o  sonso  oirouit  I r.u  k--  Iho  volt.ir.o  .u  ro---.  .i 
rosistor  dividi-r  notuork  .it  tin-  SSI'i'  oiiti'iit.  Iroin  thi-  it  r.onor.it  o--  Iho  --t.ilir 
-.i\;nal  lor  tho  oontrol  loi-.io.  Volt.i.po  --onsui)',  i--  in-od  in  1 loii  ol  iiirro",t 
•-i-nsuir.  lor  iinprovod  lault  isol.ilion.  , 

I'ho  oontrol  lor.io  oiniiit  iit  i 1 i -os  tho  trip  --ipii.il--,  --l.itii--  -ir.ii.il,  .nul 
tin-  oxt(-rnal  oontrol  --ir.nal  a--  uoll  a--  oro  oiirn-nl  ori'-'-iii);  .nul  oro  voll.ir.o 
orossinr,  signals.  It  vorlii---  that  Iho  input  ooiinn.nul  i--  valid  .nul  lontiol-- 


230  V,  400  HZ 


FIGURE  10.  SOLID-STATE  POWER  CONTROLLER  (SSPC) 
FUNCTIONAL  DIAGRAM 


the  SfR  switeh  drive  eiivuit.  Hsinu  .inothei'  iiipiit  it  eoiitrols  the  use  of  the 
SSl'i’  in  either  the  uoniuilly  open  (V.tl.l  iiKuie  or  noniiallv  elosed  (N.tl.l  mode. 

rieet  romaitnet  ie  interferenee  is  minimized  In-  turninp,  on  the  SCR's  at 
zero  voitai^e  erossiny  and  tuniiny  them  off  at  zero  eurrent  erossin.u. 

I'aeh  power  eontrol  module  consist:’  of  tour  SSl’d's  rated  at  J amperes 
RMS,  all  wired  to  the  same  phase  of  one  o!'  tlie  d.^0  \ \d,  10('  llz  luiwer  buses. 
The  conti’ol,  status,  triji  and  [lower  outputs  .'ire  se[)arate  Cor  each  SSl’C. 
Individual  CailsaCe  functions  are  provided  for  tlie  power  outputs 

The  standai’d  SSI’C  is  ilesijtned  to  funct  ional  ly  I’oplace  a nonually 
oiien  relay,  fhis  means  that  the  iiower  is  "off"  when  the  command  is  P J \'1X‘, 
and  "on"  when  energized  by  a .'S  b VIK',  command  siiiiial.  Some  SSI\''s  can  Ih' 
jumpei’ed  to  either  a nonna  1 ly-open  (N.fl.l  or  nouiial  ly-closed  (N.l'.l  ^vnifiy 
urat ion. 

fhe  obJ'-'Ctive  of  converting  specific  l^'l  electi’omechanical  power 
controllers  to  solid  state  power  controllers  was  to  reduce  tlie  life  c\cle 
costs  of  the  Power  (ionti'oller  Assemblies  (PtiA's).  The  cost  savings  would 
be  realized  in  lower  acquisition  costs,  reduced  support  costs,  reduced 
volume  requirements,  less  weiyiit,  and  imiu’oved  re ! iab  i I i t >•. 

Increiisetl^  I'ltegrat  iimi 

Rased  on  the  exiK'i’ience  liained  in  tlie  R I liMUX,  multipliw  sistems  for 
future  strategic  or  tactical  aircraft  will  lie  extended  to  lu’ovide  increased 
integration  of  aiionics,  flight  instruments,  and  power  control  functions. 

In  particular,  the  interface  wiring  lietween  tiie  nu’ltiiilex  remote  teniiinals 
and  the  power  control  assemblies  (PC.M  can  be  reduced  if  the  PtlA'  • can 
comimuiicate  directly  with  the  multiplex  ilata  bus  or  if  serial  digital  channel 
are  provided  between  the  I'.MUX  reimite  ti'nuinals  and  the  Pl'A's.  In  the  present 
system,  the  PllA's  are  in  close  proximity  to  the  PMUX  remote  teniiinals  but 
three  pairs  of  wires  are  used  for  each  power  controller,  flierefore,  a great 
multiplicity  of  wires  c;ui  be  replaced  with  a few  twisted  shielded  ['airs  in 
either  the  multiiilex  aiijiroach  or  in  using  the  TMIIX  serial  digital  channels. 

Althoug.h,  the  presetit  imister  caution  displai’  panid  is  control  U'd  In- 
I’.MII'C,  each  iiarallel  discrete  signal  requires  a wire  pair.  Rv  integrating 
a multiplex  terminal  in  the  master  caution  panel,  the  wiring  can  be  great  1\ 
reiiuced  in  the  instrument  panel  area  which  is  extremely  constricted. 


Witli  tlio  iiKT(.';isi.'il  aMit'uk'iico  Kiruli  has  Ihx'm  );.iiiu\l  tlirouv:h  tlu'  h 1 
tost  provii'.mi,  multiplox  t oohti iquos  oaii  i'o  oxtoiulo.l  to  otlior  systoms  aiul 
tiuiotioiis  wliioli  Koiv  not  initially  oaiulidatos  1\m-  mul  t ipl  ox  iny..  An  oxamplo, 
is  tho  powor  yonorat  ion  anJ  hu;-  Jist  rilnit  ion  svstoin.  IVlioroas,  i'^RI\  onl\ 
jM’ov  iiloJ  load  manayoiiiont  and  status  ol'  tliis  svstom,  tho  intoyrat  ion  ot 
yonorator  oontrols  and  systom  controls  »\ith  tho  r,MH\  imiltiidox  cajiahilitv 
is  vindor  cons  i do  rat  ion  and  studv. 

t>n  a laryo  aircraft  sucli  as  tho  B 1,  iho  uso  of  throo  major  imiltiplox 
svstoms  was  iustit'iod  hasod  on  tho  haixlwaro  stato  ol'  tho  ait,  accoptanco  I't 
mill  t iploxiny  at  tho  incopt  ion  of  tho  proyram,  a”d  numlior  of  siynals  to  ho 
handlod.  i'ho  contractual  partitioniny  of  tho  proyram  was  "^uch  that  an  associate 
contractor  intoyixitod  tho  avionics  aiui  dovolopod  a separate  itiul  t i(i!('x  s\stom 
(.\M1I\).  In  tho  fiituro,  and  part  icularlv  for  smallor  aircraft,  tho  uso  of  a 
sinylo  multiplox  systom  would  ho  dosirahlo.  I'ho  oporat  ional  oxporionco 
yainod  with  IMIX  indicatos  that  provisions  for  rodundanc\'  can  ho  roducoil 
such  as  usiny  a sinylo  l.MUX  multiidox  soct  ion  in  liou  of  two  indopondont 
soot  ions. 
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ABSTRACT 


This  paper  describes  the  development  and  operation  of  a universal 
multiplex  which  satisfies  the  requirements  of  MIL-STD-1553A,  MDC 
3818,  and  MIL-G-85013  and  is  consistent  with  the  proposed  MIL- 
STD-1553B. 

First,  background  information  is  provided  on  CONRAC  programs  which 
led  to  the  development  of  the  multiplex.  Following  this,  a detailed 
description  of  a universal  bus  controller  Interface  unit  (BCIU)  is 
given.  The  paper  closes  with  descriptions  of  three  programs  which 

utilize  this  BCIU.  k 


1.  INTRODUCTION 


The  multiplex  architecture  described  in  this  paper  utilizes  the  knowledge  and 
experience  gained  in  many  years  of  designing,  developing,  and  producing  MIL-SPEC 
avionics  multiplex  bus  systems.  The  following  is  a list  of  programs  involving  mux 
bus  technology: 

• US  Navy  Universal  Locator-Airborne  Integrated  Data  System 

• NASA  Space  Shuttle  Engine  Interface  Unit 

• US  Air  Force  F-15  Signal  Data  Recording  Set 

• US  Navy  F-18  Stores  Management  Set 

• NASA  Space  Shuttle  Ground  Command  Interface  Logic  Unit 

• US  Navy  LAMPS  Mux  Bus  Tester 

• US  Navy  F-18  Communications  System  Control  Set 

As  a result  of  the  ULAIDS  program,  which  required  a distributed  processing 
system,  Conrac  designed  a generalized  architecture  which  could  be  used  for  both 
polled  contention  and  command  response  requirements.  This  architecture,  designated 
Integrated  Data  Acquisition  and  Display  System  (IDADS)  has  the  following  design 
features : 

• Communications  between  multiplex  terminals  is  either  distributed  or 
command  response  (Hybrid  System) 

• Each  multiplex  terminal  is  self-contained  and  Intelligent  and  is  cap- 
able of  initiating  or  responding  to  transmissions  from/ to  other  terminals 
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• Each  terminal  is  software  controlled  and  except  for  I/O,  is  similar 
from  a hardware  standpoint,  thus  achieving  commonality  and  standard- 
ization among  the  various  multiplex  terminals  in  a system 

a The  varying  requirements  of  a user  (data  terminal)  are  configured  into 
the  system  by  I/O  cards  connected  to  the  microprocessor  bus  in  the  multi- 
plex terminal.  These  data  terminals  are  universal  and  include  displays, 
data  entry  devices,  analog  inputs,  digital  inputs,  avionics,  weapon  systems 


• IDADS  is  flexible  and  capable  of  expansion.  The  system  can  be  configured 
with  any  number  of  data  stations. 


2.  IDADS  DESCRIPTION 


IDADS  is  an  Integrated  MIL-STD-15S3A  data  syati^ni  using  distributed  process- 
ing and  conmunlcatlona.  In  the  IDADS  system,  each  user  Is  an  intelligent  terminal 
capable  of  direct  communications  to/from  any  other  terminal. 


Figure  1 Is  a block  diagram  of  Conrac's  IDADS  approach.  Communications  be- 
tween each  of  the  terminals  Is  accomplished  using  a polled  MIL-STD-1553A  (redundant) 
bus  technique  which  makes  use  of  a Conrac-developed  floating  bus  controller.  The 
Individual  terminals  are  Internally  self-sufficient  in  that  they  are  capable  of 
processing  any  data  that  Is  collected  and  Initiating  communications.  The  work 
load  for  the  system  is  distributed  among  the  various  subsystems  and  thus  the 
overall  data  processing  speed  Is  Increased. 

Each  station  connected  to  the  multiplex  bus  consists  of  a multiplex  terminal 
(communications  Interface)  and  a data  terminal.  The  multiplex  terminal  is  a 
standard  hardware  configuration  containing  a bus  Interface  unit,  microprocessor, 
and  an  I/O  controller.  The  I/O  controller  is  designed  to  interface  with  the  data 
terminal.  The  system  allows  interfacing  of  the  multiplex  terminal  with  any  type 
of  data  terminal  under  software  control.  The  data  terminal  can  be  a display  sub- 
system, tape  recorder,  data  entry  device  analog  signal  conditioner,  avionic  sub- 
systems, etc. 

I 

The  floating  controller  provides  for  communicat ions  on  the  bus  using  MIL-STD- 
1553A  protocol.  In  this  technique,  bus  control  is  handed  to  the  next  designated 
station  (under  software  control)  after  the  station  has  completed  its  communica- 
tions. An  important  aspect  of  this  approach  is  flexibility  and  capability  for 
expansion.  A system  can  be  configured  with  any  number  of  data  stations.  Also, 
the  IDADS  approach  allows  for  interconnecting  of  subsystems  to  form  a multiple  j 

loop  system.  (See  Figure  2.)  Each  IDADS  loop  is  interconnected  by  a node  terminal. 

The  node  terminal  performs  intercommunication  between  IDADS  loops.  In  this  manner,  j. 

an  integrated  system  is  generated  which  performs  communications  between  various  [ 

subsystems.  i 
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The  IDADS  multiplex  terminal  was  developed  to  satisfy  the  requirements  of 
MIL-STD-1553A,  MDC  3818,  and  MIL-G-85013,  and  is  consistent  with  the  proposed  1553B. 
This  was  accomplished  using  a microprogrammable  controller.  The  approach  resulted 
in  a design  of  a multiplex  terminal  which  was  used  in  ULAIDS,  F-18  (Stores  Manage- 
ment Set  and  Communication  Systems  Controller)  and  the  LAMPS  MUX  BUS  TESTER.  The 
F-18  program  is  a subset  of  the  ULAIDS  program  such  that  a ULAIDS  terminal  could 
be  plugged  into  an  F-18  test  fixture  and  function  perfectly.  As  a matter  of  fact, 
multiplex  terminals  with  ULAIDS  microcode  are  used  as  bus  controllers  for  testing 
F-18  hardware  (SMS  and  CSC).  The  ULAIDS  program  utilizes  432  of  the  512  word  PROM 
and  the  terminal  may  act  as  a response  terminal  or  a bus  controller,  depending 
upon  activation  from  the  mux  bus  (i.e.,  receiving  a bus  offer  word)  or  from  its 
own  host  CPU  (i.e.,  by  being  given  a forced  bus  command).  The  ULAIDS  terminal 
satisfies  completely  the  polled  contention  requirements  of  85013.  A terminal 
which  is  a bus  controller  may  give  up  the  bus  by  sending  a bus  offer  word  to 
another  terminal.  When  this  terminal  receives  the  word,  it  interrogates  its  host 
computer  and  either  accepts  or  rejects  the  bus  offer.  If  it  rejects  the  bus  offer, 
it  passes  it  on  to  the  next  terminal  in  the  chain.  If  it  accepts  the  bus  offer, 
it  merely  replies  with  status  and  assumes  command  of  the  bus  on  which  the  offer 
was  given.  The  ULAIDS  terminal  is  also  capable  of  commanding  RT  to  RT  transfers. 

The  LAMPS  MUX  BUS  TESTER  contains  the  same  multiplex  terminal  with  a different 
microcode.  Most  of  the  versatile  ULAIDS  microcode  modules  have  been  utilized,  how- 
ever. Here,  upon  command  from  the  host  computer,  the  terminal  acts  as  either  a 
LAMPS  response  terminal  or  as  a monitoring  terminal.  A large  variety  of  options 
are  available  in  either  mode.  A bus  commander  capability  has  been  incorporated  into 
the  microcode  as  a possible  future  feature  for  the  tester. 

2.1  Bus  Interface  Unit 


The  block  diagram  of  the  BIU  is  as  shown  in  Figure  3.  The  heart  of  the  multi- 
plex is  the  controller  Z3.  The  multiplex  is  connected  to  two  buses,  A and  B,  on 
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one  end  and  has  DMA  capability  to  the  host  computer  memory  on  the  other.  Oeneral 
signal  flow  for  received  messages  as  a response  terminal  is  through  the  front  end 
transformer,  through  Zl,  the  mux  Z2,  the  controller  Z3  and,  via  the  DMA,  to  main 
computer  memory.  For  transmitted  messages  as  a response  terminal,  the  flow  is 
from  main  menniry  through  the  DMA,  to  the  controller  Z3,  Into  the  register  7.4  and 
out  via  the  front  end  transmitter  In  71.  Wliether  or  not  a message  Is  for  the 
particular  terminal  is  determined  by  the  address  recognition  circuitry,  77.  When 
a valid  command  sync  has  been  recognised  and  the  correct  address  la  present  In 
the  first  five  bits,  a signal  is  sent  to  the  controller  73,  wlUch  forces  the  ROM 
address  to  the  RT  entry  point,  IFF.  At  IFF,  there  la  a ("’"P  li''  program 

and  the  incoming  command  word  la  processed.  If  the  Incoming  message  la  a receive 
message,  all  the  data  wv^rds  are  stored  indirect  and  Indexed  hv  the  wv'rd  count. 

If  the  Incoming  message  is  a transmit  message,  all  the  data  words  are  fetched 


indirect  and  indexed  by  the  word  covint . In  either  case,  the  ci'ut  roller  p\it  a v'ut 
the  8 least  significant  bits  of  the  block  pointer  address.  The  8 most  significant 
.bits  are  contained  in  the  pointer  page  register,  which  la  written  bv  the  lu'st  com- 
puter. The  8 least  significant  bits  are  formed  from  the  sub-address  field  of  tlie 
command  word  and  the  T/R  bit.  Once  the  pointer  la  fetched.  It  Is  placed  In  the 
address  counter  and  the  first  data  byte  la  placed  In  tor  fetclicd  froml  tills  loca- 
tion. Actually,  2 data  bytes  are  stored  (or  fetched)  on  each  DMA  transfer  so  that 
the  memory  bvis  Is  not  tied  up  fv^r  long  periods  of  time.  The  word  count  Is  stripped 
from  the  command  word  and  stored  separately  In  a 2d01  register.  When  fw»'  data 
bytes  are  stored  (o*"  fetched),  this  covint  la  decremented.  At  0,  no  more  data  Is 
handled  and  the  mux  prepares  to  transmit  status.  Status  Is  fetche,!  from  main 
raemviry  immediately  upvnv  address  reciign  1 1 U'u  In  order  t meet  I’i'^'A  turnaiiuuul  lime 
(2  to  5 microseconds).  The  multiplex  nvvrmally  operates  In  bus  Interi  upiable  iih'de 


as  a respvuiae  terminal.  Wivlle  it  Is  processing  <'ne  bus,  a valltl  cvuiimand  wind  on 
the  other  bus  will  cause  the  mux  to  switch  over  and  process  this  data. 

The  mux,  operating  as  a bus  commander,  cont Inuous 1 v Interrogates  the  main 
computer  to  find  out  If  there  Is  a command  word  ready  to  be  transmitted,  and  If 
the  terminal  Is  to  continue  to  be  a bus  controller.  When  there  Is  a v'»'mman>l  word 
ready,  the  mux  places  the  command  wvvrd  advlress  (lower  8 bits  - uppei  8 bits  I rom 


pointer  page  register)  on  the  memory  bus  after  gaining  control  and  fetches  the 
command.  The  terminal  determines  from  the  conmand  word  the  type  of  transfer 
required  (terminal-to-controller , controller-to-terminal , or  termlnal-to-terminal) 
and  stores  and  fetches  the  data  accordingly.  When  the  transfer  is  complete,  the 
terminal  again  Interrogates  the  host  computer  for  command  word  ready  (CWK)  or 
command  request  flag  (CRF).  If  the  CRF  has  been  withdrawn,  the  terminal  program 
jumps  to  the  bus  offer  routine.  Here,  the  bus  offer  word  is  fetched,  along  with 
2 other  words.  They  are  the  terminal's  address  and  the  address  of  the  last  terailnal 
in  the  chain.  The  bus  is  then  offered  to  the  first  terminal  in  the  chain  via  the 
bus  offer  word  (subaddress  all  zeros,  word  count  all  zeros).  If  this  terminal 
responds  with  status  (indicating  it  has  received  the  message),  the  mux  shuts  down 
after  returning  to  the  RT  state.  If  no  terminal  responds  to  the  bus  offer,  an 
error  code  is  set  in  a word  which  is  written  in  the  host  computer  memory  and  an 
Interrupt  is  issued. 

Omitted  from  the  general  block  diagram  is  the  power  switching  circuitry.  Since 
most  RT's  are  active  only  5Z  of  the  time,  considerable  power  may  be  saved  by 
switching  power  onto  the  proms  only  when  the  RT  address  is  recognized.  This  is 
done  in  the  case  of  this  terminal. 

2.1.1  Front  End 

The  front  end  is  shown  in  Figure  4.  It  consists  of  a discrete  receiver  with 
a 5-pole  filter,  a hybrid  transmitter,  an  LSI  encoder /decoder , a transformer  assem- 
bly, and  an  8-stage  shift  register  for  each  channel. 

The  encoder /decoder , provided  by  Harris  Corp.,  takes  bipolar  (Manchester  en- 
coded) data  from  the  receiver,  validates  the  sync  field,  checks  for  correct  Man- 
chester encoding  and  provides  output  status  signals,  NRZ  data,  and  a clock  for 
shifting  data.  On  the  transmitting  end,  it  provides  a shift  clock  and  a signal 
which  goes  true  when  NRZ  data  can  be  accepted  [SEND  DATA  (SD)].  It  accepts  a 
transmit  command  and  NRZ  data,  as  well  as  a level  indicating  what  type  of  sync  is 
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Figure  U.  Z1  Front  End  niock  Diagram 


to  be  provided  (comnand  or  data)  and  provides  a properly  encoded  1553A  output  with 
sync  and  parity  Included. 

The  receiver  Is  composed  of  J op  amps,  a five-pole  filter  and  a dual  compaia- 
tor  per  channel. 

The  transmitter  Is  a hybrid  device  frv»m  CTI,  which  accepts  digital  M.inchester 
encoded  Inputs  and  provide*?  an  output  approximately  sinusoidal  wliich  conform:,  to 
MDC  3818  and  hence  to  1553A  and  85013. 

2.1.2  Input  Multiplex  (22)  (Figure  5) 

12  Is  a trl-state  multiplex,  which  Is  enabled  by  RDO  and  provides  one  of 
three  D Inputs  to  the  2901  devices  of  Z3.  The  last  bus  on  which  a valid  comimind 
was  received  steers  the  data  via  the  signal  BUS  B ACTIVE.  The  other  twki  t)  Inputs 
to  the  2901 's  are  the  memory  data  bus  (DB0-l)B7)  and  a constant  sub-fleld,  composed 
of  the  first  8 bits  of  the  512  x A8  bit  ROM  field. 

2.1.3  Controller  (Z3)  (Figure  6) 

The  heart  of  the  Conrac  Universal  Multiplex  Is  the  controller,  which  is  built 
up  of  a 2901  chip  set.  It  contains  a 512  x 48  bit  control  PROM,  a pipeline  regis- 
ter, 2 2901  4 bit  slices,  a 29811  next  address  controller,  3 2911  microsequencer 
controllers,  a lb:8  front-end  status  multiplex,  .i  24:1  test  condition  multiplex, 

2 counters  for  determining  when  half  a data  word  has  been  received  .uid  when  halt 
a data  word  has  been  transmitted,  and  a 2:4  demultiplex  for  selection  of  tl>e  proper 
D input  to  the  2901 's. 

The  PROM  field  is  broken  into  4 sub-fields  which  .«re  defined  .i.s  follows; 

a.  2901  Control  - 19  bits 

b.  Sequencer  Control  - 18  bits 

c.  Transmit  and  Power  Control  - 4 bits 

d.  DMA  Control  - 7 bits 
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Some  fields  do  multiple  duty  in  the  program.  For  example,  the  next  address 
field  (R0-R8)  is  also  used  to  store  constants  in  Che  2901  (R0-R7)  and  is  used  as 
input  to  the  DMA  control  register  (R0--R3). 

A list  of  the  instructions  which  have  been  defined  for  the  architecture  is 
shovm  in  Table  1.  All  of  the  arguments,  mnemonics  and  constants  have  been  defined 
using  the  definition  phase  of  AMD's  AMDASM  meta-assembler.  The  assembly  phase  was 
used  next  to  construct  a workable  microcode  set.  Each  microword  consists  of  a 
statement  for  each  of  the  four  fields  defined  above,  separated  by  (e.g.  CLR  RO 
& CJS  CARRY  & TRNS  & I^IWT) . 

A list  of  Che  micro-control  field  bits  is  shown  in  Table  2,  along  with  the  de- 
scription of  each  bit's  function. 

The  basic  instruction  clock  race  is  3MHZ.  Maximum  clock  race  for  Che  archi- 
tecture is  about  4MHZ. 

The  controller  provides  the  following  outputs  Co  other  blocks: 

a.  11  lines  to  control  Che  DMA(Z5). 

b.  3 lines  to  control  the  loading  and  shifting  of  data  to  the  output  shift 
register,  ZA. 

Three  Inputs  AEA  + ^B,  FBCF,  SYSTEM  RESET,  and  MUX  RESET  force  a jump  to  loca- 
tions IFF,  IFE,  IFD  and  IFC  respectively.  AEA  OR  AEB  occurs  on  address  recognition 
when  Che  terminal  is  an  RT  and  causes  a jump  to  Che  RT  sequence.  FBCF  is  Che  forced 
bus  command  and  is  a bit  written  by  the  host  CPU.  This  forces  an  entry  into  the 
bus  commander  routine.  SYSTEM  RESET  forces  Che  mux  into  a reset  condition  on  power 
turn  on,  and  MUX  reset  is  a bit  written  by  Che  host  CPU  which  does  the  same  thing. 
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Table  1.  Arlthmacic  Instructions  (Bits  21  thru  J8) 


MNEMONIC 

ARGUMENTS 

1 

INSTRUCTION 

NOP 

AREG,  BREG 

NO  OPERATION  Y » AREG 

CLR 

REG 

CLEAR  REGISTER  Y - 0 

RDFY 

D.  REG 

D ►REG  Y - D;  NL,  RS,  IS,  - 

RDAY 

D,  AREG^  BREu 

D ►BREG  Y - AREG  . - - * ' " 

MOV 

AREG,  BREG.  CNTRL 

AREG ►•BREG Y - 'AREA;  NL,  RS,  LS,- 

ANDD 

D.  AREG,  BREG  ' ■ 

’'AND'  D * AREG ►BREG;  NT,  RS,  LS,  - 

INC 

REG 

Increment  REG ►REG 

DEC 

REG 

Decrement  REG  ► REG 

INCAY 

AREG,  BREG 

Increment  BREG— ►BREG,  Y AREG 

DECAY 

AREG,  BREG 

Decrement  BREG — ►BREG,  Y • AREG 

ROR 

REG 

Rotate  REG  right  one  bit 

ROL 

REG 

Rotate  REG  left  one  bit 

OR 

AREG.  BREG.  CNTRL 

'OR'  AREG  + BREG— ►BREG;  NL,  RS,  LS,  - 

AND 

AREG.  BREG.  CNTRL 

'AND'  AREG  ® BREG -►BREG;  NL,  RS,  LS , - 

ORD 

D,  AREG,  BREG,  CNTRL 

'OR'  'D'  + AREG ►BRFG;-NL.  RS,  LS,  - 

XORD 

D.  AREG,  BREG,  CNTRL 

'XOR'  'D'eARDG ►BREG; 

XNORD 

D.  AREG,  BREG,  CNTRL 

'XNOR'  Tm-AREG ►BREG:  NL.  RS,  LS,  - 

XOR 

AREG,  BREG.  CNTRL 

'XOR'  AREG9 BREG— ►BREG;  NL.  RS,  LS,  - 

XNOR 

AREG,  BREG,  CNTRL 

'NOR'  AREG PBR EG —►  BREG,  NL,  RS,  LS,  - 

DADD 

?,  AREG,  BREG.  CNTRL 

(D  + AREG't  ►BREG,  NL,  RS,  LS,  - 

ADD 

AREG.  BREG,  CNTRL 

(AREG  + BREG) ►BREG;  NL,  RS,  LS,  - 

SUB  1 

AREG,  BREG,  CNTRL  1 

(.AREG  - BREG) ►BREG;  NL,  RS.  LS,  - 

SEQUENCER  CONTROL  INSTRUCTIONS 

JZ 

C,  CONSTANT 

Tump  to  location  zero 

CJS 

C.  ADDRESS 

Call  svibrout  Ine  if  C = T 

CJP 

C.  ADDRESS 

Branch  if  C » T 

PUSH 

C,  COUNTER  VALUE 

SAVR  - RETURN  .•iDD;  If  C ■=  T LO.AD  CNTR 

JSRP 

C,  P (ADDRESS'! 

C « F CALL  VIA  'R'  REG;  C = T CALL  VIA  T' 

JRP 

C,  P (.VDDRESS) 

C - F JMP  VIA  'R'  REG;  C - T JMP  VTA  T’ 

RFCT 

C.  CONSTANT 

C - F NXT  ADDR  - STACK;  C » T NXT  .ADD  - 

PC;  ALU  'D'  ST.ACK  i CONST  .ANT 

RPCT 

C,  P (ADDRESS  1 

C =•  F NTiT  ;ADDR  - ' E ' ; C » T NXT  ADDR  ' DC 

CRTN 

C,  CONSTANT 

C - T STACK  « NXT  ADDR;  CONSTANT 

CJPP 

r,  'P'  (ADDRESS) 

C - T 'P'  NXT  ADDR.  AND  POP  STACK 

LOtH’ 

C.  CONSTANT 

C - F NXT  .A!DR  - ST.ACK;  CONSTANT 

CONT 

C,  CONSTANT 

CONTINUE;  CONST.ANT 

JP 

C,  'P'  (ADDRESS) 

Unconditional  jump  to  'P'  ADDRESS 

rR/VNSMlT/rOKTR  CONTROL  INSTRUCTION  D.  (AR>  . (BRK  CT 

TRNS 

PWR  OFF.  XMIT  CONTROL 

DEFAULT  = NOP  See  TRfVNS  CONTROL  BIT  DEF 

TEST  MULTIPLEXER  CONTROL  INSTRUCTION 

TEST 

INPUT  NAME 

r DEFAULT  - DON'T  CARR 

'i 
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Table  1.  Arlthmatic  Instructions  (Bits  21  thru  38)  (Cont) 


DMA  CHANNEL  CONTROL  INSTRUCTIONS 


U30  - 9 

10  A)  NEXT  ADDRESS  FIELD 

11 

13  B)  LOOP  COUNTER  LOAD  FIELD 

14 

15  C)  ALU  CONSTANT  5.  MASK  FIELD 

16 

U30  - 17 
U28  - 9 


29811/2911 

SEQUENCE  INSTRUCTION  FIELD 


U28  - 15  TEST  INPLT  ^a'LTIPLEXER 

I 16 

U28  - 17  ADDRESS  FIELD 


TRANSMIT  ENABLE  TO  H-ARRIS  DEVICES 
TRANSMIT  SHIFT  REG  PARALLEL  LOAD 
TRANSMIT  COMMAND/DATA  Sl-NC  SELECT 


ALU  SOURCE  OPERAND  CONTROL 
FIELD 


ALU  FUNCTION  CONTROL 
FIELD 

ALU  DESTINATION  CONTROL 
FIELD 

ALU  REGISTER  SELECT  FIELD 
OUTFIT  TO  B FORT 


26  - 

14 

1 

15 

26  - 

16 

26  - 

11 

19  - 

9 

1 

10 

Table  2.  Mux  Bus  Micro  Control  Field  (Cont) 


BIT# 

MNEMONIC 

PROM  & PIN 

DESCRIPTION 

37 

38 

A2 

A3 

U19  - 15 

U19  - 16 

ALU  39 

L 

U19  - 17 

ALU  'D'  INPUT  MPX  LS  ADDRESS  BIT 

NA  40 

CRCL 

U9  - 9 

DMA  CONTROL  REG  LOAD  ENABLE  BIT 

NA  ^2 

U9  - 10 

11 

DMA  CHANNEL  REQUEST  BIT 

DMA  CHANNEL  RELEASE  BIT 

NA  43 

DCLK 

13 

DMA  CHANNEL  DATA  REG  LOAD  ENABLE  BIT 

44 

NA  45 

ADDCLK 

ACL 

14 

15 

DMA  CHANNEL  ADDRESS  REGISTER  CLOCK  BIT 

DMA  CHANNEL  ADDRESS  REG  PARALLEL  LOAD  BIT 

NA  46 

IRXX 

16  ! 

HOST  COMPUTER  INTERRUPT  REQUEST 

NA  47 

ROM  PWR 

U9  - 17 

ROM  POWER  OFF  BIT 

PI  - U9;  P2  - U19;  P3  - U26;  P4  « U24;  P5  - U28;  P6  = U30 


2-1.4  Parallel  to  Serial  Output  Register  (Z4)  (Figure  7) 

This  register  is  loaded  via  control  from  Z3  with  a particular  2901  output 
register.  Its  output  is  serial  and  is  input  to  the  Harris  encoder/decoder.  The 
clock  is  the  encoder  shift  clock. 

2.1.5  DMA  Control  (Z5)  (Figure  8) 

The  DMA  control  consists  of  a memory  interface  and  a CPU  interface.  The 
memory  interface  consists  of  16  address  lines,  8 data  lines  and  2 control  signals 


(MEMW  and  MEMR) . The  CPU  interface  consists  of  the  hold  request  (HLD  REQ) , the 
hold  acknowledge  (HLDA) , the  phase  2 clock  and  the  interrupt  request. 

The  DMA  is  under  total  control  of  the  controller  function  Z3  via  11  lines. 
Lines  are  provided  for  loading  the  control  register,  loading  and  clocking  the 
address  counter,  loading  the  data  register  and  controlling  the  CPU  interface. 

It  must  be  noted  that  there  are  2 address  sources,  the  address  counter  (16 
bits);  and  the  pointer  page  register  (8  bits)  and  2901  outputs  (8  bits).  V/hich 
set  is  enabled  to  the  bus  is  determined  by  the  control  register  signal  ADDRS. 
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When  ADDRS  Is  high,  the  counter  is  enabled.  Wlien  it  is  low,  the  alternate  address 
set  is  enabled.  No  address  set  is  enabled  unless  HLDA  is  true. 

2.1.6  CPU  Writable  Add/Or  Readable  Registers  (Figure  9) 

The  host  computer  conmiunicates  with  and  controls  the  multiplex  via  2 sources: 

a.  3 mux  registers 

b.  2 memory  words  labeled  FLAG  WORD  I and  FL/VC  WORD  2 contained  in  main 
memory . 

The  3 mux  registers  are  the  status  register,  the  terminal  address  register 
and  the  pointer  page  register.  The  upper  half  of  the  status  register  is  writable 
but  not  readable  by  the  CPU.  Three  control  bits  may  be  written  - MUX  reset, 
which  resets  the  mux  to  a quiescent  or  power  down  state.  BCA  vrtiich  commands  the 
mux  to  be  commander  of  bus  A and  forces  t r.ansuctlons  to  take  place  on  this  bus 
and  BCB  whlcli  does  the  same  thing  for  bus  B. 

The  lower  half  of  tlie  status  register  contains  2 read.able  bits  which  Inform 
the  computer  of  bus  activity  on  A or  B since  the  last  read.  Reading  these  bits 
clears  them. 

I, 

The  pointer  page  register  contains  the  upper  8 bits  of  the  block  pointer  ad-  ■ 

dress  for  each  sub-address.  There  are  64  double  word  pointers  occupying  128  loca-  ' 

tions.  On  this  page  are  also  stored  FI.AC  WORD  I,  R.AC  WORD  2,  STATUS  (2  words),  t 

1; 

the  last  command  word  (2  wi>rds)  and  the  last  MODF.  command  weird  (2  words).  ^ 

The  terminal  address  register  allows  the  termln.il  address  to  be  programmable  ' 

s 

b*  the  host  cvimpviter.  It  also  contains  tl\e  FBCF  bit,  which  causes  the  mux  to  ij 

the  bus  commaniler  riile.  It  is  used,  for  example,  in  ULAIDS  to  sel.'.e  the  bus  J 

wt  •••!  there  has  betut  .i  lack  of  bus  activity.  'i 

;( 

^ 1 
I 
I 

< 
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The  address  recognition  block  is  used  only  wt^en  the  terminal  is  an  RT.  U 
consists  of  one  5 bit  magnitude  comparator,  one  timer  circuit  and  one  flip-flop 
per  channel.  When  a valid  command  word  has  been  received,  CS  goes  high  enabling 
the  counter-timer.  After  five  bits  have  been  received,  the  counter  enables  the 
address  comparison.  If  true,  the  signal  AEIA  or  AEB  is  generated  which  forces 
the  controller  (Z3)  to  service  the  Incoming  word  or  words  as  an  RT. 


Figure  10  Z7  Address  Recognition 
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3.  APPLICATIONS 

3.1  ULAIDS 

The  ULAIDS  system  is  designed  in  accordance  with  Conrac  IDADS.  Figure  11  is 
a block  diagram  of  the  ULAIDS  system  which  consists  of  five  airborne  stations: 


• Engine  Signal  Acquisition  and  Control  Terminal  (SACT  1) 


• Aircraft  SACT  (SACT  2) 

• Aircraft  Health  Monitor  Recorder  (AMHR) 

• Flight  Incident  Recorder  and  Universal  Locator  (FIR/UL) 

• Master  Monitor  Display  and  Data  Entry  Panel  (MMD/DEP). 

In  accordance  with  the  IDADS  approacht  each  subsystem  Is  capable  of  Initiating 
communications  with  other  subsystems  to  gather  data  and  give  information  regarding 
failures  and  out-of-tolerance  conditions.  The  Individual  subsystems  are  internally 
self-sufficient  in  that  they  are  capable  of  processing  any  data  that  is  collected 
and  initiating  appropriate  action  based  on  the  result  of  the  processing.  It  is 
important  to  note  that  except  for  an  I/O  controller  card,  the  multiplex  terminals 
are  identical.  Figure  12  is  an  outline  drawing  of  the  multiplex  terminal. 

The  SACT  terminals  are  capable  of  conditioning,  processing,  and  transmitting 
the  status  of  engine  sensors,  aircraft  sensors  and  WRA's.  The  SACT's  are  programmed 
to  perform  sampling,  formatting,  parameter  checking,  and  evaluation  of  data.  Out-of- 
limits  conditions,  determined  by  predetermined  algorithms,  are  transmitted  to  other 
terminals  in  accordance  with  the  IDAD’s  communications  protocol. 
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11.  ULAIDS  System  IDADS  Configuration  Block  Diagram 


Figure  12.  Multiplex  Terminal  - MMD/DEP  Outline 


The  MMD/DEP  consists  of  a Data  Entry  Panel,  a Master  Monitor  Display,  and  a 
Multiplex  Terminal.  Information  to  be  displayed  is  received  by  the  Multiplex  Ter- 
minal via  the  bus  and  processed  in  accordance  with  a prescribed  program.  The  pro- 
cessed data  is  fed  to  Che  symbol  generator  contained  within  Che  multiplex  terminal. 

The  output  of  the  symbol  generator  is  a video  signal  in  TV  format  which  is  fed  to  the 
display  unit.  Specific  data  can  be  called  up  for  display  by  the  Data  Entry  Panel. 

The  MKD  has  the  capability  for  generating  out-of-limits  history  information.  This 
information  is  accumulated  from  the  last  initialization  and  is  stored  in  a non-volatile 
memory. 

The  Aircraft  Health  Monitor  Recorder  (AHMR)  records  data  which  will  subsequently 
be  analyzed  in  a ground  terminal.  This  data  will  consist  of  snapshot  data  and  out- 
of-limits  data. 

Snapshot  data  represents  a complete  10-second  frame  of  information  relating  to 
engine  sensors,  aircraft  sensors,  VJRA's  and  equipment  status.  This  data  is  trans- 
mitted at  fixed  intervals  and  upon  command  from  the  DEP. 

Out-of-limits  data  relates  to  detection  of  fault  conditions  and  parameters 
exceedances  as  detected  by  SACT  processing.  This  includes  category  of  the  error, 
location  of  the  error,  and  dump  of  the  last  values  of  all  sensors  when  the  error 
occurred.  The  tape  recorder  has  the  capabilities  of  recording  3 hours  of  data 
information. 

The  HR/UL  provides  a non-volatile  record  of  audio  and  data  Inputs  which  can  be 
recovered  and  analyzed  in  the  ground  terminal  if  a crash  occurs. 

The  ULAIDS  mission  is  designed  to  improve  the  following  operational  requirements 
of  the  aircraft: 

• Flight  Safety  - by  continuous  monitoring  and  display  of  aircraft  sub- 
systems 


• Mission  Effectiveness  - by  continuous  monitoring  and  display  of  current 
readiness  at  mission  essential  systems 

• Logistics  Efficiency  - through  the  standardization  and  modularization 
of  equipment  and  software. 


3.2  LAMPS  Mux  Bus  Tester 


i 

^ Conrac  Model  608T6  Mux  Bus  Tester  is  a portable  test  Instrument  desinged  for 

use  in  fault  isolation  and  checkout  of  aircraft  installation  using  the  MIL-STD-1553A 
command /response  or  MIL-G-85013  polled  terminal  multiplex  bus  configuration.  Model 
608T6  features  a microprocessor  controlled  diagnostic  capability  and  displays  results 
in  alphanumerlcs  on  an  easily  readable  front  panel.  The  analyzer  (see  Figure  13) 
is  contained  in  a rugged  compact  suitcase  enclosure  and  features  the  following  cap- 
I abilities: 


• Detect  invalid  sync  fields 

• Detect  invalid  Manchester  II  codes 

• Detect  invalid  information  fields  (16  BITS  and  parity) 


i 


• Checking  proper  response  time 

• Checking  proper  protocol  between  terminals 

• Checking  BIT  error  rate  as  defined  in  paragraph  4. 3. 3. 2 of  MIL-STD-1553A 

• Checking  proper  voltage  levels 

• Checking  proper  BIT  rate 

• Perform  diagnostics  under  software  control  (microprocessor) 
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• Display  multiplex  bus  status  on  an  easily  readable  front  panel 


• Transmit  diagnostic  information  to  remote  terminals 

• Detect  and  verify  number  of  words  in  message 

• Display  all  data  received  in  engineering  unit. 

3.2.1  Description 

A block  diagram  of  Conrac  Model  608T6  multiplex  bus  tester  is  shown  in  Figure  14. 
The  tester  operates  In  two  modes: 

• Monitoring 

e Interactive. 

In  the  monitoring  mode,  data  on  the  bus  Is  fed  Into  the  tester  and  all  traffic 
Is  checked  for  normal  operation.  The  bus  data  is  fed  into  a multiplex  terminal  con- 
troller. This  controller,  using  a microprogrammer,  is  capable  of  interfacing  with 
either  the  command/response  or  the  polled  contention  multiplex  configuration  and  re- 
acts with  the  bus  as  if  it  were  a standard  terminal.  The  basic  difference  is  that 
the  terminal  does  not  respond  to  requests  but  rather  stores  data  received  or  trans- 
mitted by  terminals  which  are  in  communication. 

These  communications  between  terminals  are  stored  in  the  microporcessor  core 
memory  and  can  be  called  up  for  display  using  the  data  entry  keys  contained  in  the 
unit.  The  block  diagram  shot;s  that  the  data  from  the  multiplex  bus  is  also  fed  to 
the  signal  analyzer  which  monitors  the  line  condition  and  detects  the  following 
conditions: 


j 

i 

f 

! 

i 
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hi(;iirc  l/t.  I.AMI’S  Multiplex  Bus  Tester 


• Invalid  sync 


• Invalid  Manchester  code 

• Invalid  information  field 

• Invalid  response  time 

• Invalid  voltage  levels 

• Invalid  BIT  rate. 

This  information  is  also  fed  to  the  microprocessor  for  storage  in  memory  and 
correlated  with  the  specific  communication  between  the  terminals  under  consideration. 
This  is  also  displayed  on  the  front  panel  in  an  alphanumeric  format.  The  system 
can  also  be  programmed  to  perform  diagnostics  on  the  messages  if  the  specific  content 
of  the  message  is  nredetermined . The  results  of  the  diagnostics  are  presented  on 
the  display  panel. 

In  the  interactive  mode  the  tester  acts  as  an  additional  multiplex  terminal  in 
Che  system  and  transmits  and  receives  messages  from  other  terminals.  Varied  diag- 
nostic techniques  can  be  incorporated  under  program  control.  One  approach  allows 
Che  tester  to  request  specific  data  from  the  terminals  and  check  for  proper  content. 

A second  approach  is  to  transmit  canned  messages  to  other  terminals  to  be  used  for 
retransmission.  In  both  of  these  techniques  the  BIT  error  rate  of  the  system  can 
be  determined.  The  diagnostic  results  are  displayed  on  the  front  panel. 

Specific  test  modes  Chat  can  be  accomodated  in  the  interactive  mode  are  the 
following: 


• Add  noise  to  the  transmitted  message 
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Generate  an  invalid  sync  in  the  transmitted  message 


• Generate  invalid  Manchester  code  in  the  transmitted  message 

• Generate  invalid  message  field  in  the  transmitted  message 

• Generate  vari>.as  voltage  levels  in  the  transmitted  message 

• Generate  invalia  BIT  rate. 

3.3  F-18  Communications  System  Control  Set  C-10382/A 

The  Conmunication  System  Control  Set  (CSC)  being  designed  by  Conrac  for  the 
USN/MCAIR  F-18  is  the  total  interface  between  the  AN/AYK-14(V)  Mission  Computer  (MC) , 
the  pilot  operated  'Up  Front  Control  (UFC)  panel  and  the  17  associated  Communication, 
Navigation  and  Identification  (CNI)  subsystems  on  board  the  aircraft.  The  CSC  pro- 
vides operator  and  computer  control  of  these  systems  and  the  transfer  of  data. 

Operations  in  the  CSC  involve  conversion,  storage  and  transfer  of  digital,  ana- 
log, synchro  and  discrete  data. 

The  F-18  CSC  provides  the  intelligence  and  power  to  the  UFC  panel  and  in  terms 
of  energy  management  powers  up/down  those  CNI  subsystems  as  required  by  the  pilot 
through  the  UFC  panel. 

The  concept  of  the  CSC  is  to  integrate  control  of  all  CNI  equipments,  thereby 
eliminating  proliferation  of  cockpit  controls,  and  consolidating  these  controls  into 
the  UFC  panel  for  reduced  pilot  workload. 

The  doubly-redundant  MIL-STB-1553A  Bmltiplex  (MUX)  conmectlona  from  the  F-18 
CSC  to  the  AN/AYK-IA  Mission  Computer  (MC)  provides  a port  for  flow  of  information 
and  control  between  the  MC  and  the  CSC  and  CNI  equipment.  Flow  of  control  can  only 


be  from  the  MC  to  the  CSC,  but  Information  of  display  on  the  alphanumeric  display 
of  the  UFC  panel  (scratchpad  and  options)  also  flows  from  the  MC  to  the  CSC.  The 
Information  that  flows  from  the  CSC  to  the  MC  consists  of  equipment  status,  received 
data,  and  operating  options  of  equipment.  BIT  commands  and  BIT  status  also  flow 
through  the  MUX. 

The  requirements  of  the  F-18  CSC  are  to  process  data  to  and  from  the  CSC, 

Mission  Computer,  Up  Front  Control  Panel,  and  CNI  equipment.  To  accomplish  this 
task,  the  CSC  interfaces  the  following  types  of  signals: 

• Serial  Digital 

• Discrete 

• Analog 

• Synchro 

• Multiplex. 

Besides  Interfacing  these  various  types  of  signals  the  F-18  CSC  processes  at 
least  1300  parameters  per  second.  To  accomplish  this  requirement,  Conrac's  CSC 
contains  a fast  microprocessor  which  controls  and  processes  the  required  data  leaving 
over  80  percent  of  real  time  available  for  growth. 

3.4  US  Navy  F-18  Stores  Management  Set  AM/AYQ-9(V) 

The  Conrac  Stores  Management  Set  (SMS)  for  the  USN/MCAIR  F-18  consists  of  an 
Armament  Computer  CP-1342/AYQ-9(V) , two  Wing  Tip  Decoders,  four  Pylon  Decoders,  two 
Fuselage  Decoders  and  a Gun  Decoder.  Figure  15  is  a photo  of  the  Armament  Computer. 
Figure  16  is  a system  block  diagram. 
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Figure  F-18  SMS  Interface  Diagram 


Th«  SMS  Accapts  multiplex  M1L-STD-1553A  bus  digital  data  and  hard  wire  signals 
ffom  the  aircraft  avionics  and  controls  and  uses  these  signals  to  deploy  the  stores 
for  their  Intended  purpose. 

Through  the  MIL-STD-1553A  multiplex  bus,  the  Armament  Computer  Interfaces  the 
AN/AYK-14(V)  Mission  Computer  and  Cockpit  Controls.  On  the  outboard  side,  the  Arma- 
ment Computer,  through  a special  low  power,  dedicated  Conrac  version  of  the  1553A 
Mux  Bus,  controls  all  of  the  Stores  Stations. 


The  F-18  SMS  Is  the  most  modern  state-of-the-art  of  such  avionics  systems  em- 
ploying digital  MIL-STD-1553  multiplex  and  microprocessor  techniques  with  designed 
in  Reliability  and  Maintainability  and  a 98  percent  self-test  capability. 
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(HISTORY  OF  PARAMETER  LIMIT  EXCEEDANCE 
WITH  FAULT  ISOLATION) 
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BASIC  AVIONIC  SUBSYSTEM  INTEGRATION  CONCEPT 
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EIKCTRONIQUE  NARCEl  DASSAULT  art  wvirking  iiincr  I >>70  in  the  field  of 
multiplex  dat«  huaex  at  I NHr . 

Thua  El  Kl'TRON IQUE  MAROEl  DASSAID.T  have  xuceessively  studied  the 
following  nxiltiplex  information  transfer  systems  through  eontraets 
under  French  Authorities  : 


H?!!  - l<>7)  : bus  for  Missiles, 

I '*7  1 - l'J7b  : GINA  bus  for  Aircratt, 

I97S  - 1977  : directly  derived  from  GINA  bus  , a bus  tor  NAVY 

appl icat ions . 


Svich  studies  now  concretised  by  several  operational  appl  icat  ii^tts,  as 
the  recent  French  military  programs,  issued  by  D.T.C.A.,  D.T.E.N.  and 
D.G.A.N.,  are  all  using  the  GINA  bus  for  transfer  of  information 
between  equipment. 

The  purpose  of  this  statement  is  to  explain  some  essential  characte- 
ristics of  the  GINA  bus. 
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* • ’ * DEFINITIONS 

'.I.*.  Hus  lin^i'V  "bus" 

This  IS  ( bt‘  transmission  svipv'^'i  ^ toi  vii^ttal  int^Min.ition 
t'voro  a \m\U  iv'lox  oxoban^jo  svsit'm. 

J . I . . Hus  oont  VO  1 U*  r { 

This  uiu  t insutos  organisation  ot  oxohangos  on  t ho  bus 
in  autononvHis  tlooal  iik'Jo)  or  in  liaison  with  on«*  ot  t ho 
svstom  oomputt'i  (ohannol  I'X'iioK  It  must  bo  oonnootod  to 
tlu  main  bus. 

J.l.  1.  Ronx'to  terminal^ 

Kach  rotiK't^*  unit  oonnaoteJ  with  the  bus  lino  oomprisoa  : 

- the  equipim'nt  itself, 

the  oouplers  as  neoessarv  for  oonneotion  of  the 
oquipRM'nt  to  the  bus  lino, 

. 1.4.  Ooupl  er^ 

Is  the  mime  given  to  .a  tunotiv'nal  asseniblv  being  a p.ivl 
of  oaoh  renx'te  tonninal  aiul  is  genorallv  intogratovl  in 
oaoh  unit  ; it  realises  the  oonneotion  o!  the  equipim'nt 
itself  with  the  bus  lino, 

Suoh  assemblv  is  oomposod  of  : 

* bus^k'ou^U^r  ^s} 


Vho  bus  ovMiplei  is  the  element  insuring  vonne»tion 
with  the  bus  line  ; its  vletinition  texe«'pt  tvM  ledun- 
danev>  .ind  the  tunetions  it  pertv'ims  aie  ulentie.il  tot 
all  e^pi  i piiu'nt  . It  is  onlv  a tunotion  ot  the  detinition 
ot  the  tiansmission  svstem  and  o\\‘hanges  ot  gan  i .‘at  i on 
on  the  bus.  It  ^allies  out  all  logu  opeiations  that 
must  pettorm  ,i  I I units  ov'nneoted  onto  a same  bus. 

'd  . ^ U I i 1 • L ‘1* . ' ' 'J  I'  ^ ‘ 1 1 ' S S ' 


Vho  sub-svstew  oouplei  peitoim  the  funot ions  bound  to 
the  transmission  svstem  whieh  ate  not  iiiv  lud'd  in  the 
bus  lOuplei  is'  and  thus,  speeitie  to  t ht'  lequitements 
ot  the  equipment  into  whieh  it  is  inttgtated. 

I'hvs  i e.i  I I N , the  sub*svstem  vouplet  insult's  the  eoupling 
ot  the  t'quipment  itse’t  with  the  bus  touplot  vs'. 
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2. 1.5.  Digital  transmission  system 

The  basic  transmission  system  comprises  (Illustration  I - 
Figure  I)  : 

the  bus-line  (redundant  if  necessary), 

the  bus-controller  (redundant  if  necessary), 

the  standard  bus  couplers  for  each  equipment. 

From  the  basic  transmission  system,  some  sub-buses  may  be 
connected  to  the  main  bus  (see  Figure  2 - Illustration  1). 

Other  combinations  may  be  also  used. 


2.2.  OPERATIONAL  SAFETY 

Redundancy  allows  for  a gxid  safety  of  i nformat  ion  exchanges  and  for 
failure  protection. 

The  redundancy  degree  is  determined  at  each  level  as  a function  of 
specific  requirements  for  the  general  system.  For  example  (111.  2), 
the  redundancy  could  bare  upon  the  controller  and  the  main  bus,  all 
sub-buses  being  simple. 

In  all  cases,  the  couplers  COS  and  CSS  are  considered  as  being 
integral  part  of  the  equipment  and  have  not  to  be  redundant  if  the 
equipment  itself  is  not  redundant. 
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CMAPTER  III  TRANSMISSION  SUPPORT 


I . I . TRANSMISSION  SUPPORT  SfRUOTURF 
3.1.1.  Type  of  structurt* 

Equipmt'nc  connect  iop  on  the  bus  line  (peripheral  P)  is 
made  by  stubbing  . the  main  line  being  not  inte»'rupted  by 
th»'.^  connect  ion  of  a peripheral. 

3 . 1.2.  Connect ing  mode 

liaison  between  equipment  and  the  bus  is  made  through 
transit  -mers  with  a stubbing. 

3.1.3.  l.iaison  type 

The  digital  information  exchange  system  is  organized 
around  two  lines  : 

- one  procedure  line  (LP)  is  unidirectional  . on  which  the 

controller  emits  the  procedure  words  destined  to 
equipment , 

- one  data  line  (LD)  bidirectional  onwhichdate  (emission 

and  reception)  are  tranamitred . 
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3.2.  INTKR-EQUIPHKNT  LIAISON  CONCEPT 

Tran  mins  ion  support  oon»trni.-t  i on 

Tht'  cable  usej  is  a twisted  pair  with  double  shielding, 
closed  at  both  ends  on  its  charact er i st  i c impedance. 

E I ei^t  r ^CjS  I ^ij^a r ac  t e r i s tics  o^  1 i ne 

The  line  used  must  have  a charact er i st ic  impedance  : 

2c  of  7SA  ♦ ST 

Attenuation  caused  bv  a 100  m length  ot  cable  on  a sinu- 
soidal sijtnal  at  1 MHr  must  be  le  SS  ^ 

Adapt  at  ion 

At  both  ends,  the  line  is  fitted  with  the  followintt  network: 


R - 7SA  ♦ IT  0.  S W 

i,’  — 

Rj  - UlK.n«  ST  0.2SW. 


3 . 2 . •» . Shie  1 d i ng 

At  each  point  where  the  shielding  is  interrupted  ie>^iiipment 
connection,  bus  termination,  bulkhead  crotaiag  , etc...', 
it  must  be  connected  to  framework  bv  means  ot  as  short  as 
possible  a liaison.  I'nlv  the  two  wires  of  the  line  should 
pass  through  the  wall,  the  ground  liaison  being  made  1 1 om 
out  side . 


'..'.S.  Bus  topology 

Ei'r  di'tinitivMi  iM  t lu'  bus,  tlu*  tolK'wing  i egui  ri’iiuMit  s must 
be  strictly  observed  : 

The  line  port  ion  between  two  consecutive  stubbs  must  be 
longer  than  the  sum  of  the  stubbs  length. 

- The  length  of  a stubb,  measured  'torn  the  mam  bus  to  the 
tr.inslormer  of  the  equipment  must  not  exceed  l.s  m. 

I'n  the  bus.  there  must  not  exist. inv  wav  longei  than  that 
necess.irv  1 1>  gi'  from  one  .idapt  at  ion  netwvrk  to  thc,othct 
12" 
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CHARACTERISTICS  OF  TRANSMISSION  SIGNALS 


Informations  are  transmitted  under  differential  mode  in 
series  on  the  lines  at  the  rate  of  t megabit  per  second. 

Modulation  and  code  type 


The  code  used  is  a biphase  code  with  return  to  zero  and 
thus,  modulation  is  at  three  levels.  The  continuous  compo- 
nent, null  at  the  bit  level,  allows  the  use  of  transformers 
in  good  conditions. 


'll' 

■ 1 , 0 . 0 t I 

n I n ' n n 


bi  t 

signal 
on  1 i ne 


Electrical  characteristics 

Emitting  levels  : ^ 6V  ♦ IV  on  37.541 
Reception  thresholds  : + 2.25V  + 0.25V 
- Conmon  mode  rejection  ; 

I.i  the  frequency  band  0 to  2 MHz,  any  signal  of  a peak 
amplitude  inferior  or  equal  to  + 25V  between  line  and 
ground  does  not  impair  the  liaison  performances.  In  addi- 
tion, any  signal  of  peak  amplitude  inferior  or  equal 
to  + 50V  is  not  liable  to  dammage  definitively  the  asso- 
ciated equipment. 
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CHAPTER  IV  SySTEM  OF  EXCHANGES 


INFORMATION  ELEMENTS  TRANSMITTED 

4.1.1.  Character 

A character  is  an  information  element  composed  of  10 
inseparable  bits  at  transmission. 

These  10  bits  are  grouped  according  to  the  following  format: 


The  V bit  signification  depends  upon  the  type  of  the  charac- 
ter (procedure,  echo,  data)  in  which  it  is  included. 

The  field  0 contains  the  useful  byte. 

The  P bit  is  an  imparity  bit  hearing  on  the  whole  -character 
(odd  number  of  "i"  or  "0"). 

4.1.2.  Chain  of  characters 


The  characters  may  be  grouped  in  sequence  to  form  chains 
of  I to  256  characters. 


4.1.3.  Word 

The  characters  may  be  grouped  to  form  words.  The  data  word 
format  transmitted  is  free. 

4.1.4.  Message 

A message  is  an  assembly  of  characters  carried  on  a line  as 
a unique  block  (without  "gap"). 

4.1.5.  Informational  content 


When  an  information  is  coded  in  several  bit  contained  in 
one  or  more  fields  of  the  useful  byte  these  will  be  trans- 
mitted most  significant  bit  ahead. 

When  an  information  is  coded  on  several  bytes  the  charac- 
ters containing  them  are  transmitted  most  significant  bit 
ahead . 
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4.2.  EXCHANGK  EXECUTION 


4.2.1.  Exchanges 

An  exchange  correspinids  to  the  eiisemhle  of  nx'ssages  carried 
on  the  bu.s  from  one  single  initiation  of  the  bus  controller 
(U.C.  ) . 

It  runs  in  two  steps  : 

Bus  configuration  (sub-buses  connection)  and  pre-selec- 
tion of  those  peripherals  concerned  by  this  exchange. 
This  function  is  vn-rfevrraed  bv  the  VI. G.  by  means  of  the 
procedure  line. 

Uata  transfer  (if  any)  between  preselected  units 
(among  which  occasionally  the  U.G.)  through  the  data 
I i ne . 

The  exchange  is  monitored  by  the  (i.C.  by  means  of  the 
mess.-ge  it  emit  through  the  procedure  line. 

4.2.2.  Peripheral  synchronisation 

The  synchronisation  of  the  peripherals  is  carried  out  ; 

at  the  bit  level  : by  the  auto-sync  modulation, 

at  the  character  level  : by  counting  the  bits, 

at  the  message  level  ; by  envelope  detection, 

at  exchange  level  ; by  the  messages  included. 

Any  receiver  utilizing  a message  controls  : 

the  imparity  bits  of  the  characters  herein, 

- its  format  (concrete  number  of  10  bits  characters 
received) . 

4 . 2 . 1 . Exchange  procedure 

4 . 2 . 1 . 1 .  Exchange  structure 

Illustration  ) cepresents  the  messages  circulating  mi 
I..P.  and  1..D.  lines  in  execution  of  an  exchange. 

The  pvvH'odure  message,  issued  ixi  l.P  by  the  U.G.  is 
including  : 

- a chain  of  comaand  words  of  two  characters  each 
(command  phase), 

occasionnal ly  , a chain  of  delaying  characters 
(delay  phase,  if  any), 
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occ«*ionniinv,  a rhain  of  ari  vii-r  oliai  art  oi  a 
(data  phaae,  if  any), 

a aorvicp  oharaotfr  for  «*nd  of  axi-hanno  *• 


Th^  aufcpaaiva  data  iw*aBagpa,  omittpd  hv  cqviiimont  on 
I..D.  are  of  t%*o  typaa  : 

acknowlpd)(pnH*nt  of  pro-aoloot  ion  and  alatua  oi  rclu' 
from  addrpaard  olom'nta  (oomnand  pliaao),  I'mitlod  i<ii 
l..n.  by  pquipna'nt  aa  doa i (inat  od  bv  ovimv  > onxn.itul 
vMrd , 

data  mt'aa.i)|P  iaavird  bv  Dir  priipbrial  rmillri, 
i'litapiiard  of  : 

. onr  I'bain  of  data  rbarai'trra, 

. onr  data  rbarartrr  for  rnd  of  r xiliaiinr* . 


Hrmark  : Kvrnliiallv.  wtirn  arrurity  of  ( i anami  aaion 
would  hr  mandatorv,  aiirh  arrvirr  <>r  data  rhaiaitria  ol 
rnd  of  rarhangr  could  contain  a longitudinal  impaiitv 
braring  on  tlir  wliolr  procrdnrr  or  data  mraaagr. 


4.2.).  2.  Bua  configuration  and  rquipinrnt  yrrarlrction 

Such  oprrat  iona  arc  carrird  out  during  the  coiianand  pliaar 
by  thr  roomand  wvirda  iaaiird  on  l,.r.  bv  thr  control  In 
U.G. 


Thr  coimand  irorda  havr  thr  following  tormat 
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4. 2. 3. 2.  I, 


Coniiuind  word  chain  structure 


The  conmand  phase  could  be  separated  in  successive 
sub-phases,  corresponding  to  the  various  sub-buses 
involved  in  the  exchange.  During  each  sub-phase  , 
the  controller  U.G.  emits  on  L.P.  a sub-chain  of 
cooinand  words  destined  to  equipment  connected  to  the 
corresponding  sub-bus. 

Each  sub-chain  comprises  : 

- the  comnand  words  destined  to  the  peripherals  of 
the  sub-bus  (if  any), 

- one  additionnal  conmand  and  connection  word. 


4 . 2 . 3 . 2 . 2 . Sub- buses  connect  ion  and  peripheral  addressing 

Connection  of  a sub-bus  is  carried  out  by  a sub-bus 
coupler  CSB  addressed  by  a CC  . 

On  a sub-bus,  no  information  is  circulating  prior 
to  the  start  of  the  corresponding  command  sub-phase. 
For  an  equipment  connected  to  this  sub-bus,  the 
conmand  sub-phase  begins  only  when  the  message 
appears  on  L.P.  and  it  terminates  at  the  end  of 
receipt  of  the  first  CC  . 


Remark  : An  equipment  ignores  it  is  connected  on  a 
sub-bus;  for  it,  the  conmand  phase,  limited  to  the 
sub-phase  on  its  sub-bus,  is  exactly  the  same  as 
for  a single  bus,  without  any  sub-bus. 

4. 2. 3. 3.  Exchange  execution 

4. 2. 3. 3.1.  Succession  of  phases 

An  exchange  is  displayed  into  three  main  phases  : 

- Conmand  phase. 

- Occasionnal ly  , delay  phase. 

- Occasionnal ly  , data  phase. 

An  end  of  exchange  phase,  not  seen  by  equipment  , 
is  always  associ.ited  ti'  these  three  phases  at  tin- 
transmission  level  (SCI-  parag.  4.2.  3.  1.1. 
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4.  ».  ADDRESSES  OF  THE  EQUIPMENT 

Attributiun  of  address  to  equipment  (peripheral  or  CSB)  must  bo  done 
as  a function  of  the  exchange  system  ensemble  and  of  its  management. 
The  following  rules  must  be  followed  due  to  the  procedure  : 

on  a given  sub-bus  , all  peripherals  must  have  different  addres- 
ses, 

address  N - 0 is  prohibited  for  CSB  and  peripherals, 

during  an  exchange  , the  bus  configuration  must  never  be  such 
that  several  CSB  of  same  aduress  (if  any)  could  be  simul t aneousl v 
addressed . 
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CHAPTER  V 


EXCHANGE  SYSTEM  MANAGEMENT 


5.1.  EXCHANGE  WDES 

Expi'ut  ion  of  an  cxi'hango  may  imply  I wo  tvpoa  ot  aol  ion  ; 

limoit i at  •’  apt  ion  of  U.G.  on  por  i plioral  s bv  moans  v'l  .-ontnaiul 
words . 

Data  Iranslor  bolwoon  por  i phoral  s tl'G  inolvidodl  sviboi  d i nal  oj  to 
oxistenop  of  a data  phasp. 

Both  tvpps  ot  act  ion  aro  i ndopondmit  1 v ooniioll<'d  bv  i bo  I’G  and 
may  bo  s imiil  t anoons  toontonl  of  t bo  oommand  phase  and  issm’  ol 
bits  V • I nonovatinR  the  data  pbasi'l  . 

Tho  following  twv'  oonoopt  s allow,  for  oaih  I vpo  ot  aotii'it.  to 
olaasifv  the  pxohandps  ; 

pxplioit  : N tioUl  of  oommanvl  words. 

implioit  : 

. l.abol  fbroadoaat  modo^  Jpoodinn  for  ppriphorals. 

. Inlprnal  oporation  for  I'.G.  oontrollor. 

opnf  ra  1 i 3!pd  : I'G  is  implioifolv  addressed  and  oxebanpos 
take  plaeo  between  I'G  and  pei  i phi'ial  s . I'G 
does  not  omit  echo  on  the  bus. 

doeent  ral  i red  ; Exeh.anges  take  plane  between  peiipberals  and 
when  VC  is  eonei'ined  it  is  explioitelv 
addressed  as  a m'rmal  peiipbeial  . It  has 
then  on  addiess  A aitd  is  issninp  an  I'obo  .'n 
the  bos. 
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5.2.  OATA  EXCHANCK 

The  data  t'xihan)(e  is  condi  t ionned  by  ; 

tho  ooninand  phaso  whiiti  detincs  th»-  type  of  oxchango  , 

tho  oxistonoo  ot  tho  data  phaso  fbits  V • I on  1..1’.)  whiiti 
oxooutos  tho  transfor. 

Tho  UC  oontiollor  oan  thon  dooido  to  oarry  out  or  not  tho  data  tians- 
for  , i ndopondont 1 y from  tho  command  phaso  contents. 

At  this  lovol  , it  appears  nocossarv  to  dofino  tho  tol lowing  concopi  s 
rolativo  to  data  oxchanjto  : 

explicit  tlocaO  : X field  of  command  words, 
implicit  igonorall  : Label  (broadcast  model. 

Informations,  proper  im'aninjt. 

Status  data. 
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As  .»  m’not.i!  lull'  .inv  oijuipim'ul  ulili:*iu):  a mos>.i»;r  vtu-iixs  its 
inli'y;iit\  at  t lu'  li.msmission  lovrl. 

1 1 ausmi  ss  i oil  » lio»  Ws  ai  i’  as  »ollows  : 

Impaiitv  ilu'»ks  oi  ail  vh.iiailoi  ooniiu'sni^  t hr  r.H’ssa>;o. 

Koimat  I’ho.  K ot  ;iu‘ssai’,o  at  t ho  ouJ  of  { i anscn  ss  i oti  . I ho  j.'ta) 
luimhoi  ot  n tuts  loioivovl  must  ooiiospoiul  to  a oonoioti  numho  i 
K I't  ohavaotots  *'t  li'  hits  : ii  ■ I t'K . 


I.v>ii^  i t lul  i tia  1 inipaiitv  ohovk  ii 
^ I . t . 


I ho  mossav'.o  has  it  vsoo  paiao. . 


Whon  .ill  I'nuipnu'iit  vlotoots  a tault  \u  a wossay^o  t i aiisiiu  ss  i on . 

. It  stops  iiiiiioii  i .It  o I V .ill  I'liiots  osooiuion  v i in' I ml  i n^*.  ihoso 
altoaviv  lovoivoj  witlunit  otiv'il  vontainoii  in  th.if  nH’ssap.o 
iooninanii  oyooutii'ii  , d.it.i  tiansli’i,  oto..,^  .nul  looks  on  st  aiul 
hv  until  tho  ouil  v't  t ho  ninning  moss. 10,0. 

. It  irn'inorisos  tho  oiioi.until  tho  oiul  v't  tho  oommaiul  ph.isv' 
whioh  will  ho  soon  in  i lu'  next  oxohanjio. 

. Whon  oxplioitolv  .uUlrossoil  in  tho  noxt  osoh.uu'.o  it  p^'inis  vuit 
tho  ovror  hv  plaonii;  a VH  hit  • 0 in  its  ooho. 
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h.J.  INTtXJRll’Y  iHKiKS  OK  KXOHANilK  SYSTKM 
SiK'h  shocks  aro  pt*itottn»*d  bv 

- t ho  nKMUtorinjt  t'lonH'iUs  t ho  oxohan^i-  svstom 

“ spoiitio  olomoiUs  whon  soomitv  i't  oxoh.u\jt»‘S  is  nandatotv 
Whook  ol  bus  oont  1 Rui  .U  u>n«  010...K 

o.J.I.  Olu  i ks  \ vittiod  i'ut  bv  t ho  UO*S 

'^uoh  ohoiks  Jopouds  upon  t lu*  «tottnitiou  o!  t ho  oxihan>ii‘ 
svstom  mana^onu  U . In  t'ldoi  lo  loali/o  thoso  ihoiks,  t l»o 
UG*S  oan  utili^o  t ho  ti'lK’wing  iiU  01  mat  ions  : 

Kquipmonl  oohoos  on  whioh  t hev  aro  ohookin^;  : 

t ho  VB  bit  whioh  provulos  t ho  losults  ol  ttansmissioi 
ohooks  maUo  bv  tho  v ot  i ospouvl injt  oqvupmonl, 

oonoordaiioo  ot  addross  A with  that  ol  t ho  addiossod 
oqu  i pnH'iit  , 

’ - its  intogrilv  towards  transmission  iparitv  and 

format  ^ . 

Other  exchange  tm'ssages  on  which  thev  can-independent  I 
from  the  transmission  checks-per tom  complementary 
checks  to  be  determined  as  a function  of  manageim'nt  and 
organisation  (redundancy  at  bus  level,  managenu'nt  ,et  c . . > 
of  each  system. 

b . 2 . J . Spec  i f ic  oheckiin^  devices 

Such  devices  mav  be  placed  anywhere  along  the  bus  and  onlv 
exist  when  the  securilv  of  exchanges  is  mandators. 

The  checks  carried  out  are  determined  as  a fuiu  t ion  ol  tlu' 
securitv  requirements  tor  each  system. 

Sv'iTk'  possible  local  checks  are  quoted  be  K'w  : 

- transmission  checks, 

- true  addressing  check  ot  peripherals  (loncordance  ot 
echo  with  procedure  im'ssageK 

- bus  eonf i gurat I on  check. 
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The  two  first  types  of  checks  are  similar  to  those  perfor* 
meil  by  the  UC*S  and  nuiy  justify  direct  actions  onto  the 
managing  units. 

The  last  type  of  check  allows,  at  sub-bus  level,  to  insure 
of  its  good  connection. 

For  this,  the  checking  device  is  connected  to  the  sub-bus  : 
it  verifies  whether  the  A address  contained  in  the  echo 
issued  by  the  CSB  after  execution  of  a connect  ion  corres- 
ponds really  to  the  sub-bus  on  which  it  is  connected.  In 
the  event  of  a detected  error,  this  device  locks  out  imme- 
diately the  correspv'nd  i ng  CSB. 
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10}i  7.  Bus  Tester 


Abstract 


As  an  extension  to  the  MIL  STD  1553  databus 
a decentralized  control  method  is  described. 
It  can  be  used  in  any  combination  with  the 
standard  procedure.  A proper  adaption  of 
systemarchitecture  and  control  method  can 
give  graceful!  degradation  and  easy  recon- 
figuration and  therefore  better  system  sur- 
vivebility. 


Introduction 


In  a contract  with  German  MOD  VDO-L  developped 
as  an  extension  to  MIL  STD  1553  a method  for 
decentralized  control  of  DATA-transfer.  The 
intention  was  to  provide  an  alternative  con- 
trol-method of  DATA-transfer  for  more  sophis- 
ticated and  distributed  systems. 

The  presented  control -method  is  based  on  the 
DATA-channel  and  wordformat  of  MIL  STD  1553 
and  it  is  compatible  with  this  standard  and 
can  be  used  for  all  the  system  or  only  parts 
of  it. 


Allocation  of  Transmission  time 


In  the  basic  system  the  controller  is  alloca- 
ting transmission  time  to  the  terminals,  there 
is  no  own  activity  of  the  terminal.  Now  we 
allow  for  self i ni ti ated  transmissions  of  a 
terminal.  For  better  differentiation  in  the 
following  these  terminals  will  be  called 
"Member". 

With  many  members  being  able  to  initiate  trans- 
missions, we  have  to  avoid  excess  of  more  than 
one  at  a time.  For  this  purpose  a time  slot- 
sequence  is  used.  The  basic  lay-out  is  shown 
in  fig.  1.  All  members  are  listening  to  the 
databus.  Each  "end  of  transmission"  easily  is 
detected.  At  this  instance  a counter  is  re- 
setted  and  started,  using  the  internal  clock, 
to  generate  these  time-slots.  The  members  are 
assigned  to  different  time-slots  in  the  sequence 
of  their  priorities. 
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With  the  priority  sequence  stepping  through, 
only  the  member  with  the  highest  priority  is 
allowed  to  start  its  transmission  if  it  wants 
to  do  so.  This  fact  is  detected  by  all  other 
members  and  causes  them  to  hold  back  their 
activities. 

At  this  point  normally  there  is  the  objection 
that  members  at  the  lower  end  of  priority  se- 
quence may  not  be  able  to  get  the  bus  due  to 
higher  priority  activities.  To  avoid  this, 
there  has  to  be  spare  time  in  the  system.  But 
spare  time  easily  is  gained  by  this  control 
method  itself  and  a alarm  procedure  will  help 
too.  We  will  discuss  this  later  in  more  details. 

In  case  of  long  periods  without  activity  on  the 
bus, synchroni zati on  of  priority  sequence  coun- 
ters in  separate  members  could  be  lost.  To 
avoid  this,  a refresh  pulse  is  used.  After  one 
frame  of  the  p'ri  ori  ty  sequence  without  activity, 
it  starts  again  from  the  beyinning  and  the 
first  operational  member  in  the  sequence  gene- 
rates a refresh  pulse.  This  simulates  anend  of  trans- 
mission and  therefore  resets  and  synchronizes 
the  priority  sequence  counters  in  all  members. 

To  avoid  confusion  during  a random  power  on- 
sequence  of  different  members,  the  priority 
sequence  first  is  synchronized  to  the  current 
bus  activity  and  after  that  the  transmitter  is 
enabl ed. 

In  reality  the  priority  sequence  is  a little 
more  complicated,  we  will  come  back  to  it 
later  on. 


3 Transfer  modes 


Basically  there  are  only  2 transfer  modes: 
First  there  is  the 

3.1  Transmission  mode 


Transmission  mode  is  initiated  by  a member  it- 
self and  always  starts  in  the  time-slot,  only 
this  member  is  assigned  to  (see  fig  2).  It  can  be 
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3.2 


- periodically  with  a fixed  transfer  rate 

- periodically  with  variable  transfer  rate 
for  instance  dependent  of  change  rate  of 
this  particular  parameter  or 

- a randomly  generated  transfer. 


In  the 


A member  of  the  system  can  "ask"  for  a parti- 
cular information  by  issuing  a "request."  The 
adressed  member  can  respond  immediately  with 
a "reply  message".  A request  is  initiated 
like  a "transmission".  The  requested  member 
starts  the  "reply  message"  in  a special  time- 
slot  R (shown  in  fig.  3)  before  any  other  ac- 
tivities. So  a reply  message  normally  follows 
immediately  to  the  request. 


If  the  requested  information  is  not  available 
and  has  to  be  generated  either  by  conversion 
or  calculation,  the  reply  message  only  con- 
tains the  information  "more  time  needed". 
After  preparation  of  data,  the  requested  mem- 
ber then  starts  a standard  transmission. 


4.  Message  structure 

4.1  Transmission  message 


A transmission  message  as  shown  in  fig.  4, 
uses  the  broadcast-method.  Therefore  it  carries 
the  source  address  in  the  command  word,  we  call 
it  a 'tag-command  instead  of  recei ve-command . 

It  is  up  to  the  listening  members  to  pick  up 
those  information  they  are  programmed  to.  This 
will  be  explained  in  more  detail  in  a later 
paragraph . 

4.2  Request-reply  message 


For  the  request  a standard  transmi t-command  is 
used  (fig.  5).  The  reply  is  a transmission  as 
defined  before. 
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Alarm  mode 


Introduction  of  the  t ime-s 1 ot- sequence  makes 
it  possible  to  add  a really  fast  alarm  mode 
(see  fig.  6 ) . 

For  this  purpose  a member  can  issue  a short 
pulse  in  the  time  slot  No.  13  . indicating, 
that  it  wants  to  issue  a time  critical  message. 
All  other  members  listening  to  the  bus  now 
will  hold  back. their  normal  activities.  In 
the  adjacent  priority  sequen'c^  only  the  alarm 
message  is  transmitted. 

If  more  than  one  member  issues  an  alarm-pulse 
at  a time,  the  higher  priority  transmits  its  mes- 
sage first,  then  the  next  one  repeats  the 
alarm-pulse  and  will  transmit  in  the  adjacent 
priority-sequence  and  so  on. 

The  superposition  of  alarm-pulses  may  cause 
a distortion  due  to  propagation  delays  on  the 
bus.  But  there  is  no  difficulty  for  the  recei- 
ver (xircuit  to  detect  it  properly. 

So  with  the  alarm-pulse  the  system  switches  to 
a higher  priority  level  and  falls  back  after 
all  alarm  messages  are  transmitted. 

If  accidental  1y  a noise  pulse  appears  in  the 
Alarm  slot  the  adjacent  sequence  will  run  through 
without  activity,  but  the  system  th<.n  falls  back 
to  normal  operation. 


Supervisor 

Status  monitorin'g  and  testing  of  a system 
basically  is  a central  function.  Since  there 
is  no  central  controller,  the  system  can  be 
monitored  by  a "Supervisor".  Its  main  duty  is 
to  listen  to  the  communications  and  to  compare 
parameter  refresh  rates  with  predetermined 
limits.  If  there  normally  is  no  periodic 
emission,  the  supervisor  can  "ask"  the  member 
using  the  request-reply  mode.  A status! nforma- 
tion  with  failure  indication  as  well  as  a mis- 
sing reply  leeds  to  a failure  warning. 


Because  the  supervisor  is  limited  to  monito- 
ring functions  its  breakdown  will  not  effect 
busoperation. 

7 Safety  circuit 

7.1  Chatterswi tch 


The  problem  of  unallowed  emissions  of  a member 
due  to  hard-  or  software  failure  is  common 
all  databusses  centrally  or  decentrally  con- 
trolled. To  minimize  this  “chattering"  problem, 
we  designed  a failsafe  circuit  limiting  the 
average  of  transmission  time.  The  principle  is 
shown  in  fig.  7.  The  transmission  energy  is 
taken  from  a capacitor.  It  is  charged  through 
a series  resistor. 

The  added  circuit  stabilizes  the  output  voltage 
and  switches  it  off  if  allowed  average  is  ex- 
ceeded. This  circuit  has  not  to  be  failsafe, 
it's  for  comfort  only. 

7.2  Interference  detector 


Due  to  severe  noije  or  hardware  problems,  more 
than  one  terminal  or  member  may  take  the  bus 
at  a time.  To  avoid  more  than  oecgssary  con- 
fusion of  the  system,  an  interference  detector 
is  added.  The  principle  is  shown  in  fig.  8.  It 
compares  signals  on  the  bus  with  its  own  out- 
put. So  signals  from  other  members  easily  are 
recognized  and  the  current  transmission  is  shut 
down.  So  the  priority  sequence  starts  and  the 
system  tries  again. 

8 Compatibility  with  MIL  STD  15S3 

We  are  well  aware  that  it  may  be  necessary  to 
use  also  standard  equipment  of  the  shelf  using 
the  basic  MIL  STD  procedure. 

In  a mixed  system  (fig.  9)  for  a terminal  to 
member  transfer  these  terminals  will  be  initia- 
ted by  members  issuing  a transmi t-command.  They 
will  reoly  in  accordance  with  the  standard  in 
the  2...I0  ^us  gap  (see  fig.  lo). 
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A terminal  to  terminal  transfer  needs  the 
help  of  another  member  playing  the  control- 
lers roll.  The  resulting  communication  is 
identical  to  the  standard  and  is  shown  in 
fig.  11.  The  special  time-slot  C can  be  used 
for  this  controller  giving  it  highest  pri- 
ority (fig.  12). 

Description  of  experimental  hardware  (fig.  13) 

Using  standard  MSI  circuits,  a "databus  module 
was  developed.  For  experimental  work  5 sub- 
system-simulator boxes  where  used  to  check  out 
all  the  functions  described  before. 

The  blockdiagram  of  the  databus-module  is 
given  in  fig.  13  . 

The  interface  to  the  host-system  is  designed 
for  easy  adaption  to  all  parallel  or  serial 
bus  oriented  structures. 

The  basic  blockdiagram  should  be  selfexplai- 
ning.  So  I can  concentrate  on  some  details. 

First  of  all  there  is  a pin  to  select  the 
MIL  STD  procedure  or  the  VDO-procedure. 

On  the  receiving  side  we  added  a ROM.  Its 
addresslines  are  controlled  by  all  address 
bits  and  the  T/R  bit  of  the  received  command- 
word. 

In  the  broadcast-mode  it  allows  to  program 
all  source  addresses  and  subaddresses  this  mem 
ber  shall  pick  up.  So  only  those  information 
will  cause  a "data  ready"  and  a interrupt  to 
the  subsystem. 

This  ROM  also  contains  the  members  address. 

If  its  own  address  is  detected  in  a "request" 
"data  ready"  interrupts  the  host-system  for 
proper  reply-message. 

If  the  host-system  is  not  able  to  respond 
in  the  available  time  of  18  ,us,  a preloaded 
additional  shiftregister  wi 1 r automa cical ly 
issue  a "wait"  message. 


After  requested  data  are  available  they  are. 
transferred  via  a "transmission". 
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The  additional  shi f treg i s ter  also  can  be  used 
to  meet  the  lo  us  deadline  for  statusinfor- 
mation  in  the  MIL  STD  procedure. 

And  last  not  least  there  is  the  priority- 
center  generating  the  time-slots.  This  is 
the  only  additional  hardware  for  the  decen- 
tral control  procedure  and  represents  about 
4 X of  the  total  amount  of  hardware.  In  a 
future  LSI  circuit  it  can  be  neglected. 

Influence  to  system  design 

The  easiest  approach  is  to  program  the  mem- 
bers for  periodic  or  not  periodic  transmis- 
sions of  its  various  parameters.  At  the  re- 
ceiving side  it  may  be  programmed  to  pick  up 
what  it  is  interested  in,  and,  if  there  is 
no  sufficient  information  to  "ask"  for  it. 

And  then  forget  all  worries,  the  system  will 
take  care  of  itself. 

I know,  that  this  is  a systems-engeneer' s night- 
mare. He  is  used  to  know  exactly  what  is  going 
on  in  the  system  in  respect  to  time  and  se- 
quence . 

So  let's  do  very  little  steps. 

- First  there  is  the  small  system  (like  fig.  14) 
using  a central  computer  controlling  some 
pheripheral  elements  and  receiving  infor- 
mation from  them,  if  the  central  computer 
fails,  all  the  system  fails.  In  this  case 
there  is  no  senseful  application  of  the 
decentral  bus  control. 

- Second  there  is  basically  the  same  system,  but 
it  is  maybe  senseful,  to  preserve  some 
communication  between  peripherals  as  a 
standby  function  in  case  of  a computer  fai- 
lure (see  fig.  15).  If  operational,  the 
computer  controls  the  bus  using  a ingh  pri- 
ority time-slot.  If  it  fails,  the  peripherals 
will  continue  to  operate,  using  their  lower 
priority  time-slots. 


Third,  there  is  the  system  where  some  of 
the  terminals  have  a random  and  seldom  in- 
formation output  (fig.  16).  In  the  basic 
system  they  have  to  be  scanned  with  the  worst 
case  rate.  In  the  decentral  approach  they 
will  take  the  bus  only  if  nepessary.  And 
if  urgent,  they  can  use  the  alarm  mode. 

Fourth,  there  is  the  system  with  functional 
independent  special  to  purpose  subsystems, 
but  using  partial  the  same  data  source  and 
sinks  (fig.  17).  If  there  are  time  sensitive 
data,  for  instance  if  a differentiation  takes 
place,  each  subsystem  can  control  the  rele- 
vant sinks  and  sources  using  a fixed  rate 
and  a given  priority.  If  one  subsystem  fails, 
the  other  will  not  be  effected. 

What  I wanted  to  show  is,  that  there 
is  not  only  the  central  or  the  decentral 
control,  but  any  combination  in^etween. 


Concl usi on 


Our  intention  was  to  provide  as  an  addition  to 
the  basic  MIL  STD  an  adequate  tool  for  more 
distributed  and  more  reliable  system  architec- 
tures. Thb  right  combination  of  systemarchitec- 
ture  and  control  method  should  give  you 

- graceful  degradation, 

- simpler  and  more  transparent  software  due  to 
good  separation  of  autonomous  subsystems, 

- automatic  reconfiguration  of  a degraded 
system 

and  last  not  least 

- better  transfer  power  due  to  widely  usable 
broadcast  mode. 
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USE  OF  DIGITAL  DATA  BUSES  ON  COMMERCIAL  AIRCRAFT 


V.  J.  Small 

Boeing  Commercial  Airplane  Company 


ABSTRACT 

The  next  generation  of  commercial  aircraft  will  make 
extensive  use  of  digital  data  buses.  The  commercial  aircraft 
digital  data  buses  differ  from  the  MIL-STD-1553  buses  in 
concept  and  operation.  Commercial  buses  have  developed  by  an 
evolutionary  process,  to  meet  the  requirements  of  each 
generation  of  commercial  aircraft.  Two  digital  data  buses 
have  been  defined  for  the  next  generation  of  commercial 
aircraft;  ARINC  429  and  ARINC  453.  These  buses  will  meet  all 
the  bus  requirements  of  the  next  generation  of  commercial 
aircraft  which  will  utilize  a largely  digital  avionics  suite. 
The  two  standards  are  capable  of  growth  to  meet  possible  new 
requirements  of  future  generations  of  commercial  aircraft. 

INTRODUCTION 

The  present  generation  commercial  aircraft  utilize 
digital  data  buses  on  an  individual  system  basis,  i.e. 
Inertial  Navigation  System,  digital  air  data,  etc.  The  next 
generation  of  commercial  aircraft  will  make  extensive  use  of 
data  buses  on  an  aircraft  wide,  architectural  basis. 

To  describe  the  use  of  digital  data  buses  on  the  next 
generation  commercial  aircraft,  it  is  instructive  to  review 
the  historical  development  of  digital  data  transfer  systems 
by  the  commercial  aircraft  community,  and  the  role  played  by 
Aeronautical  Radio  Inc.  , (ARINC) . ARINC  is  supported  by,  and 
is  responsible  to,  the  airline  industry.  ARINC  sponsors  the 
Airline  Electronic  Engineering  Committee  (AEEC)  which 
formulates  standards  in  the  form  of  characteristics  and 
specifications  for  airline  electronic  equipment  and  systems, 
AEEC  subcommittees  provide  an  open  forum  where  avionic 
system  development  and  characteristic  preparation  can  be 
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conducted  with  all  interested  parties  present. 

With  the  advent  of  digital  technology,  serial  digital 
data  buses  evolved  rather  naturally  to  replace  their  analog 
counterparts.  The  serial  data  buses  were  developed  by  the 
groups  developing  the  basic  sensors.  Each  sensor  had  several 
parameters  to  be  transmitted  on  the  bus  for  reception  by  one 
or  more  user  terminals. 

A word  format  was  developed  which  consisted  of  a label 
to  indicate  the  particular  parameter  being  sent,  followed  by 
the  parameter  data  and  any  sign  or  status  indications.  The 
sensors  and  indicator  units  could  be  built  and  supplied  by 
different  manuf acturers , therefore,  the  data  transmission 
system  was  fully  defined  to  ensure  unit  interchangeability. 
This  development  philosophy  led  to  several  features  which 
were  first  incorporated  in  IQ’^l  into  the  "digital  air  data 
system"  characteristic  ARINC  575. 

o A broadcast  bus  satisfied  the  need  for  sending 

labeled  parameters  from  a sensor  to  possibly  several 
indicators . 

o The  bus  was  transmitter  controlled,  i.e.  the 
transmitter  sends  a data  word  when  the  word  is 
available  to  be  sent. 

o As  in  analog  systems,  the  indicator  was  considered  a 
data  sink. 

o A complete  data  message  was  contained  in  one  word. 

o Each  word  had  the  parameter  type  identified  with  a 
label . 

o The  transmission  system  was  fully  defined  to  permit 
unit  interchangeabi 1 i ty  on  the  bus  and 
interchangeability  of  units  between  airplane  types. 

o The  bus  used  a single  twisted  shielded  pair  wire  and 
employed  RZ  bipolar  modulation  of  the  data. 

o An  electro-mechanical  indicator  could  not  respond  to 
rapid  changes  in  input  digital  signal,  therefore,  an 
error  control  policy  of  rapid  refresh  of  information 
was  adopted. 

AEEC  at  this  time  recognized  the  potential  for 
uncontrolled  proliferation  of  data  standards  all  loosely 
based  upon  the  ARINC  575  system.  In  1973,  ARINC  produced  a 
"Digital  Data  Compendium",  (Reference  B)  which  listed  and 
defined  in  a uniform  way  the  digital  data  transmission 
systems  in  use  at  that  time.  This  document  brought  to  the 
attention  of  the  industry  the  problems  associated  with 
proliferation  of  data  standards.  In  1975,  the  Airline 
Industry  established  the  Systems  Architecture  and  Interface 
(SAI)  subcommittee  of  AEEC.  One  of  the  tasks  of  the  SAI 
subcommittee  was  to  establish  digital  data  standards  which 
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would  be  suitable  for  the  commercial  aircraft  avionics 
architecture  which  was  in  deve lopmen . A paper  by  Hart  and 
Dandakar  presented  at  the  1976  Multiplex  Conference  (Ref.  Cl  , 
discussed  the  objectives  of  the  SAI  Subcommitte  and  its  work 
up  to  that  time. 

PRESENT  STATUS 

AEEC  has  developed  an  avionic  system  architecture  and 
prepared  "characteristics"  for  the  avionics  eouipment  for  new 
airplane  designs.  In  the  area  of  digital  data  transmission 
standards,  the  SAI  subcommittee  has  developed  two 
specifications  covering  the  needs  of  the  next  generation  ot 
commercial  aircraft.  the  two  buses  characterized  are;  a 
general  purpose  bus  (ARINC  429),  and  a very  high  speed  data 
bus  (ARINC  457) . The  general  purpose  ARTNC  420  bus  can 
operate  at  one  of  two  specified  bit  rates,  12  to  14  Kbits/scc 
(similar  to  the  previous  ARINC  5'’5  busl  and  at  100  Kbits  sec. 
The  data  word  labels  are  allocated  and  the  information  liits 
are  defined  for  each  parameter  to  be  sent  over  the  digital 
data  buses  for  all  systems.  The  bus-transmitter  unit 
terminates  the  bus,  therefore,  single  bus-t r ansm i t te r 
operation  only  is  permitted.  ARINC  429  contains  any 
description  of  the  data  word  necessary  to  ensure  unit  inter- 
changeability of  the  avionics  units  built  to  the  standard. 

The  description  includes  such  items  as  maximLim  time  between 
parameter  words,  data  accuracy,  data  resolution,  and  will 
include  parameter  transport  time  and  filter  parameterr 
necessary  to  ensure  correct  operation  ot  the  avionics  unit  i ri 
conjunction  with  other  units.  Uses  of  ARINC  42H  on  new 
generation  aircraft  include;  digital  autopilot,  autothrott 1 e , 
electronic  engine  controls,  navigation,  A/N  displays,  etc. 

The  next  generation  of  commercial  aircraft  may  use 
approximately  100,  ARINC  429  buses  per  ship  set. 

During  development  of  the  ARTNC  Weather  Radar 
characteristic  (ARINC  708),  a requirement  arose  to  transmit 
digital  information  from  the  radar  T/R  unit  to  the  radar 
displays,  at  a bit  rate  considerably  higher  than  the  100 
Kbits/sec  available  from  ARINC  429.  The  SAI  subcommittee 
initiated  development  of  a "very  high  speed"  digital  data  bus 
for  weather  radar,  with  the  designation  number  ARTNC 
The  subcommittee  recommended  that,  where  appropriate,  the 
ARINC  453  bus  should  use  experience  and  technology  from 
MI L-STD-1 55 3 . The  weather  radar  subcommittee  has  define(t  a 
digital  data  transmission  system  for  the  specific  task  of 
sending  digitized  return  data  to  the  display  unit.  The 
transmission  system  utilizes  MIL-1553  technology  and 
experience  in  the  following  areas: 
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o Controlled  impedance  twisted  shielded  wire. 

o Line  terminations  and  stubbing  control. 

o Transformer  coupling. 

o Voltage  levels,  bit  rate,  rise  and  fall  times,  etc. 

o Manchester  modulation. 

o Invalid  Manchester  word  sync. 

The  word  structure  of  MIL-STD-1553  was  not  adopted  due 
to  the  specialized  weather  radar  requirements. 

At  this  point  in  time  the  requirements  for  digital  data 
transfer  for  the  SAI  defined  architecture,  can  be  satisfied 
by  ARINC  429  system  plus  the  ARINC  453  system  for  weather 
radar  display  data. 

Unforeseen  requirements  may  evolve  for  digital  data 
buses  during  the  life  of  the  next  generation  of  commercial 
aircraft  or  for  future  aircraft  generations.  It  is  important 
that  the  ARINC  digital  data  buses  have  growth  capability  to 
meet  these  possible  future  requirements.  In  the  next  section 
of  this  paper  some  comment  is  made  on  the  growth  of  ARINC  429 
and  453  to  indicate  potential,  but  not  to  recommend 
particular  implementations. 

FUTURE  GROWTH  POTENTIAL:  ARINC  429  and  ARINC  453 

The  ARINC  429  general  purpose  digital  data  bus  system 
can  evolve  and  grow  to  accommodate  a large  spectrum  of 
broadcast  applications.  The  ARINC  429  waveform  as  presently 
specified  is  capable  of  providing  the  current  necessary  to 
operate  opto-isolation  LED's.  Opto-isolation  receivers  have 
the  advantage  of  dielectrically  isolating  the  receiver  unit 
from  line  voltages.  This  feature  may  be  useful  in  a high 
lightning  transient  environment.  Another  growth  area  now 
available,  subsequent  to  the  allocation  of  a new  group  of 
labels,  is  multiple  word  messages. 

The  ARINC  453  very  high  speed  data  transmission  system 
as  presently  envisioned,  is  capable  for  growth  in  several 
ways,  for  example  word  format  and  multiple-transmitter  bus 
operation . 

The  SAI  subcommittee  has  established  that  for  future 
uses  of  ARINC  453  (other  than  weather  radar),  a 32  bit  word 
format  identical  to  the  ARINC  429  word  format  is  to  be  used. 
Figure  1.  To  maintain  similarity  to  the  ARINC  429  4 bit 
interword  gap,  ARINC  453  has  a three  bit  invalid  (high-low) 
Manchester  synchronization  pattern  followed  by  a single 
"dummy  bit"  (binary  "1")  to  ensure  a minimum  interword  timf' 
(sync  + dummy)  of  4 bits.  Future  growth  could  utilize  the 
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remaining  3 sync-plus-dummy  sequences  to  expand  the  word 
structure . 

GROWTH  OF  ARINC  453,  MULTIPLE  TRANSMITTER  OPERATION 

The  growth  of  ARINC  453  into  multiple-transmitter  bus 
operation  is  possible  on  an  evolutionary  basis.  The  ARINC 
453  electrical  characteristics  are  similar  to  MIL-STD-1553, 
therefore,  multiple  transmitter  operation  is  possible.  This 
feature  has  been  recognized  and  is  discussed  in  the  ARINC 
specifications. 

To  permit  classification  and  discussion  of  multiple 
transmitter  protocols,  it  is  convenient  to  talk  about  the 
"level  of  complexity"  of  the  bus  transmitter  unit  to  support 
the  subject  protocol.  The  "level  of  complexity"  is 
considered  to  be  in  ascending  order  depending  upon  the 
circuit  complexity  added  at  the  bus-transmitter  (bus-TX) 
unit,  over  and  above  the  simple  bus-TX  required  for  single 
transmitter  operation.  The  bus-TX  unit  is  considered  to 
include  all  functions  necessary  to  deliver  a message  onto  the 
bus . 

BASELINE:  Single  Transmitter 

The  bus-TX  is  free  to  send  a data  word  when  a data  word 
is  ready  to  be  sent.  The  bus-TX  has  no  knowledge  of  bus 
status.  No  data  storage  is  required  and  no  delay  (other  than 
normal  circuit  and  clocking  delays)  is  incurred. 

LEVEL  1:  No  Additions  To  The  Baseline  bus-TX 

A multiple  transmitter  protocol  can  be  postulated  for 
this  level,  where  transmitters  are  allocated  exclusive  use  of 
the  bus  by  some  control  element  external  to  the  bus.  An 
example  is  where  a system  utilizes  one  of  two  units  as  data 
sources  with  the  power  being  switched  from  the  main  unit  to 
the  back-up,  in  the  event  of  a unit  fault.  A second  example 
of  a protocol  at  this  level  is  where  two-way  communication 
between  units  has  been  established  on  a request/respond 
basis.  .Tp  this  way  each  unit  has  exclusive  use  of  the  bus 
and  no  clashes  result. 

Another  class  of  protocol  can  be  postulated  for  this 
level,  that  is  to  allow  two  bus-TX's  to  send  simultaneously, 
assuming  that  receiver  decoders  can  be  constructed  to 
separately  decode  the  simultaneous  messages.  McEliece  and 
Rubin,  (Ref.  D) , show  that  under  some  conditions  simultaneous 
operation  of  two  transmitters  can  provide  a data  rate  in 
excess  of  the  time-share  protocol. 
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If  the  data  transmission  rate  of  the  two  transmitters 
are  plotted  as  and  R-  and  the  capacity  is  1,  then  the  data 
rates  achievable'^with  time  sharing  the  bus  lie  within  the 
region  shaded  in  Figure  2. 

If  two  unsynchronized  bus-TX  are  permitted  to  transmit 
simultaneously  on  an  ARINC  453  channel,  then  a receiver 
connected  to  the  bus  will  sense  nine  voltage  conditions 
corresponding  to  the  combinations  of  the  three  possible 
transmitter  states;  HI,  LO,  OFF. 

If  it  is  assumed  that  two  unsynchronized  transmitters 
are  continuously  transmitting  (i.e.  transmitting  pad  words  if 
no  data  is  ready  to  send),  then  a receiver  will  sense  only  4 
states;  a low  ("0")  when  both  transmitters  are  low,  a high 
("1")  when  both  transmitters  are  high  and  an  intermediate 
level  ("2")  when  the  transmitter  states  differ.  This 
condition,  (0,2, 2,1)  corresponds  to  McEliece  and  Rubin, 
channel  C.  They  show  that  for  the  C channel,  the  combined 
rates  are  within  the  area  shown  in  Figure  3,  bounded  by  (0,0; 
1,0;  1,1/2;  1/2,1;  0,1;  0,0). 

While  the  use  of  two  transmitter,  simultaneous, 
unsynchronized  transmission  buses  is  theoretically  possible 
and  capable  of  higher  data  rates  than  time  share  protocols; 
its  use  is  difficult  due  to  the  wide  tolerance  permitted  on 
the  transmitter  output  voltages  in  ARINC  453.  It  may  be 
possible  to  redefine  the  transmitter  voltage  tolerances  and 
other  bus  parameters  to  permit  future  use  of  this  protocol. 
This  protocol  utilizes  simple  level  1 transmitters  but  the 
receivers  are  complicated  by  the  requirement  to  decode  the 
resulting  composite  signals. 

A time-shared  multiple  transmitter  protocol  can  be  used 
at  this  level  tf  clashes  are  permitted.  Figure  4 shows  the 
probability  of  clash  if  n transmitters  time-share  the  bus. 

The  following  assumptions  are  made  for  Figures  4 to  9, 
non-synchroni zed  transmitters  with  the  same  word  length  and 
same  word  rate. 

For  the  time  sharing  system  here  considered,  the 
demodulator  is  not  capable  of  decoding  data  during 
simultaneous  transmission  by  two  or  more  bus-TX,  therefore, 
transmission  clashes  are  considered  to  produce  errors  in  the 
demodulators.  This  protocol  could  be  considered  where  the 
probability  of  clash  is  so  low,  that  the  error  control  policy 
can  accommodate  it.  The  problem  of  repeated  clash  where 
transmitters  are  very  close  to  synchronism  must  be 
considered . 


LEVEL  2:  Addition  Of  Bus  Status  Detector 


The  bus  status  detector  is  only  capable  of  sensing  bus 
"free*  or  "busy".  The  bus  "busy"  status  can  be  used  to 
inhibit  the  bus-TX  to  prevent  clashes  in  a simple  two 
transmitter  non-synchroni zed  time  shared  system.  Provision 
must  be  made  at  the  bus-TX  to  store  the  data  word  in  the 
event  that  the  bus  is  busy.  This  data  delay  feature  is  not 
found  in  the  Level  1 systems  or  in  previous  ARINC  broadcast 
systems.  The  maximum  delay  suffered,  is  the  word  length  sent 
by  the  alternate  bus-TX.  The  probability  of  suffering  a 
delay  and  the  average  delay  is  dependent  upon  the  joint  bus 
loading . 

Lf  the  level  2 protocol  is  used  for  three  or  more 
bus-TX,  -...le  possibility  of  clashes  exist  following  the 
condition  where  two  or  more  bus-TX  are  delayed  awaiting 
access  to  the  bus.  Figure  5 shows  the  probability  of  clash 
and  Figure  6 shows  the  average  delay  for  this  protocol. 

LEVEL  3:  Addition  Of  Logic 

The  logic  can  introduce  a pause  before  a bus-TX  sends, 
following  a delay  caused  by  "busy"  bus.  If  this  pause  is  set 
to  a different  time  for  each  bus-TX,  then  clashes  will  be 
avoided  and  the  bus-TX  with  the  lowest  pause  (highest 
priority)  will  send  its  message  and  cause  the  other  bus-TX's 
to  be  further  delayed.  Figure  7 shows  the  average  delay  with 
this  protocol.  An  alternative  is  to  make  the  pause  time  a 
pseudo-random  number;  then  all  bus-TX's  are  identical  and 
priority  is  randomly  obtained.  With  the  random  delay  method, 
a possibility  of  clash  still  exists.  The  probability  of 
clash  is  shown  in  Figure  8 and  the  average  delay  in  Figure  9. 

LEVEL  4:  Use  Of  Data  Receiver 

The  bus  status  detector  circuit  of  levels  2 and  3 is 
replaced  with  a bus  receiver.  Logic  is  then  included  to 
extract  information  of  interest  from  the  data  being  sent  by 
other  transmitters.  An  example  of  this  level  would  be  where 
each  bus-Tx  decodes  the  word  labels  sent  by  other  bus  users. 
In  this  way,  the  bus-TX's  could  cooperate  and  send  data  words 
on  the  bus  in  a predetermined  sequence.  Appropriate  time  out 
and  logic  could  be  included  to  ensure  continued  operation  of 
the  bus,  in  the  event  of  failure  of  a cooperating  bus-TX. 

For  the  protocols  discussed  to  this  point  all  bus-TX  units 
operate  autonomously,  no  bus  controller  is  required. 
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LEVEL  5:  Use  Of  Communication  Prior  To  Sending  Message 

The  highest  level  considered  in  this  discussion  is  where 
a bus  receiver  and  extensive  processing  capability  is 
included  with  each  bus-TX.  The  bus-TX's  would  have  the 
capability  to  communicate  to  set  up  conditions  for  sending 
the  data  message.  An  example  of  this  protocol  is  MIL-STD- 
1553  where  one  bus-TX  is  associated  with  the  bus  controller 
function . 

An  example  of  an  autonomous  protocol  operating  at  this 
level  is  where  the  bus-TX's  negotiate  with  each  other  to 
determine  the  message  transmission  sequence  based  upon 
pre-established  and/or  time-dependent  message  priorities. 

The  data  v.ords  would  be  transmitted  in  the  agreed  sequence 
before  further  negotiation  would  take  place.  In  this 
example,  all  bus-TX  have  equal  authority  on  the  bus,  the 
sequence  of  words  sent  would  be  a function  of  message 
priorities  only. 

CONCLUSION 

In  conclusion  I would  like  to  mention  again  the 
evolutionary  aspect  of  digital  data  buses  on  commercial 
aircraft.  The  present  systems  are  based  upon  systems  which 
are  in  operation.  The  present  characteristics,  especially 
ARINC  453,  provide  potential  for  considerable  growth  to  meet 
possible  future  requirements.  Several  interesting  aspects  of 
research  and  development  are  involved  in  these  growth  areas. 
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ARINC  575  TO  1553A  INTERFACE 
John  F.  Howard 

ASD/ENAI3,  Wrlght-Patterson  AFB,  Ohio 


ABSTRACT 

This  paper  deals  with  the  construction  of  an  Interface  between 
MIL-STD-1553A  and  ARINC  575  specified  data  busses.  A comparison  of 
the  two  bus  systems  and  a general  description  of  the  Interface  opera- 
tion Is  presented.  Consequences  of  this  particular  design  and  possible 
areas  for  Improvement  are  also  discussed. 
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BACKGROUND 


A need  for  ASD  to  Investigate  ARINC  575  came  about  when  the  AMST  SPO 
(Advanced  Medium  STOL  Transport  System  Program  Office)  saw  a potential 
advantage  In  using  some  equipment  having  a *575  Interface.  Other  equipment 
would  use  a MIL-STD-1553A  Interface  for  standardization  purposes.  A ques- 
tion arising  from  this  situation  concerned  the  possibility  of  Interaction 
between  the  two  busses  on  the  AMST.  Also,  the  need  became  obvious  for  ASD 
engineers  to  "get  smart"  about  ARINC  575  to  allow  adequate  program  manage- 
ment and  specification  writing. 

With  this  In  mind.  It  was  decided  to  design  a simple,  quickly  built 
Interface  between  the  two  busses.  A commercial  air  data  computer  with  a 
'575  output  was  located  and  an  operating  '1553A  bus  system  was  available 
In  the  SEAFAC  laboratory.  Special  test  equipments  (Bus  Testers)  for 
debugging  '1553A  RT's  (Remote  Terminals)  were  also  available  from  SEAFAC. 

The  proposed  interface  would  accept  data  from  either  bus  and  retrans- 
mit that  data  In  correct  format  over  the  other  bus.  Data  handling  would 
progress  only  In  response  to  command  words  sent  by  the  MIL-STD-1553A  bus 
controller.  The  DEB  (Data  Exchange  Buffer)  design  would  cause  ’1553A 
operations  to  be  completely  Invisible  to  the  ARINC  575  bus.  In  other 
words,  an  Instrument  with  a '575  Input  connected  to  this  DEB  would  not 
see  any  difference  In  the  data  It  received,  although  that  data  was  sent 
to  the  DEB  over  a '1553A  data  bus. 

To  accomplish  the  design  objectives,  the  DEB  would  be  capable  of 
‘ receiving  or  transmitting  on  either  bus  system.  Since  the  two  busses 
operate  asynchronously,  provision  had  to  be  made  for  simultaneous  com- 
munications over  both  busses  and  for  temporary  data  storage  within  the 
DEB.  In  terms  of  I/O,  the  DEB  would  have  two  separate  ARINC  575  busses 
(one  for  receiving  and  one  for  transmitting)  and  two  MIL-STD-1553A  busses 
(for  a dual  redundant  system) . 

DEMONSTRATION  SETUP 


To  demonstrate  the  operation  of  the  DEB,  the  system  in  Figure  1 was 
set  up.  Data  received  by  DEB  #1  over  a '575  bus  Is  transmitted  on  com- 
mand over  '1553A.  An  RT-to-RT  transfer  from  DEB  #1  to  DEB  #2  is  used. 
DEB  #2  then  retransmits  this  data  over  another  '575  bus.  Even  though 
a double  conversion  like  this  Is  unlikely  In  an  airplane,  it  shows  the 
ability  to  convert  data  received  from  either  bus  to  the  format  required 
for  Che  other  bus. 

A total  of  10  parameters  (see  Table  1)  are  output  by  the  air  data 
computer  on  Its  '575  bus.  Although  all  of  these  parameters  are  retrans- 
mitted by  DEB  #2,  an  altimeter  was  the  only  Instrument  available  with  a 
'575  Input.  To  display  all  of  the  parameters,  a Hazeltlne  CRT  connected 
to  the  '1553A  data  bus  was  used.  When  a transfer  from  DEB  #1  occurs 
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DEMONSTRATION  SETUP  OF 
ARINC  S75/MIL-STD I5S3A  INTERFACE 


Figure 


* Matrix  00  - positive  data 

01  - no  computed  data 

10  - failure  warning 

11  - negative  data 

Refer  to  ARINC  Characteristic  575-3  for  more  information 

Table  1 


ADC  DATA  WORDS 


Parameter 

Units 

Bits/Dig.  Format 

Label (octal) 

Altitude (BCD) 

Feet 

5 

BCD 

220 

Altitude (Binary) 

Feet 

17 

BNR 

203 

Altitude  Rate 

Feet/Mln 

10 

BNR 

212 

Mach 

Mach 

13 

BNR 

205 

Computed  Air  Speed 

Knots 

12 

BNR 

206 

True  Air  Speed 

Knots 

11 

BNR 

210 

Impact  Pressure 

Inches  Hg 

12* 

BNR 

216 

Mach  Rate 

Mach/Mln 

12* 

BNR 

214 

Angle  of  Attack 

Degrees 

11* 

BNR 

215 

True  Free  Air  Temp 

Degrees  C 

10 

BNR 

213 

* Inferred  information,  not  listed  in  characteristic 


Word  Format 


Label  (8) 


Data  (21) 


over  ’1553A,  Che  bus  controller  also  copies  the  data.  Part  of  the  bus 
controller  software  identifies  the  '575  words  by  their  labels  and  changes 
the  data  into  ASCII  format  for  the  CRT.  The  bus  controller  then  sends 
this  data  to  the  CRT  for  display.  A typical  display  is  shown  in  Figure  2. 

COMPARISON  OF  BUSSES 


Although  both  bus  systems  communicate  via  serial  data  over  a single 
twisted  shielded  pair,  they  are  different  in  many  respects  (see  Table  2). 
Probably  the  most  far-reaching  difference  comes  under  the  heading  of 
"Protocol."  The  '575  bus  operates  in  a broadcast  mode,  l.e.,  a single 
transmitter  sends  data  to  a maximum  of  20  receivers.  Only  one  transmitter 
is  allowed  on  a bus;  therefore,  multiple  busses  are  needed  to  allow  for 
multiple  transmitters.  Any  unit  receiving  data  from  more  than  one  source 
is  required  to  have  a separate  input  for  each  source.  Since  communication 
is  one-way  only,  no  feedback  concerning  the  status  of  the  receivers  is 
allowed.  Also,  any  garbled  messages  will  be  lost  since  the  receivers 
cannot  request  a repeat.  An  advantage  of  the  '575  bus  over  '1553A  is  that 
the  receivers  and  transmitters  are  significantly  simpler  in  design  and 
much  slower  speeds  are  required.  Other  differences  between  the  two  sys- 
tems are  summarized  in  Table  2. 

DEB  OPERATION 


The  DEB  unit  incorporates  two  logic  cards:  an  MTU  (Multiplex  Terminal 
Unit)  and  an  SSIU  (Sub-System  Interface  Unit).  The  SEAFAC  laboratory  had 
available  an  already  proven  general  purpose  MTU  design.  This  MTU  communi- 
cates directly  over  a dual  redundant  '15S3A  bus  and  provides  a subsystem 
with  buffered  data  and  various  control  signals.  To  shorten  and  simplify 
the  DEB  design,  this  MTU  was  used  and  only  the  SSIU  had  to  be  designed. 

The  SSIU  design  is  divided  into  a '575  receiving  section,  a '575 
transmitting  section,  and  an  MTU  interface.  Control  lines  and  a clock 
from  the  MTU  are  used  to  control  the  SSIU.  Incoming  32-bit  data  words 
from  the  ARINC  575  bus  are  accepted  by  the  "receiver"  and  stored  as  two 
16-blt  words  in  preparation  for  '1553A.  On  command  from  the  MTU  (derived 
from  a '1553A  command  word),  these  stored  data  are  transferred  to  the  MTU 
and  then  out  over  the  MIL-STD-1553A  data  bus.  When  data  are  to  be  re- 
ceived over  '1553A  for  transmission  over  '575,  the  MTU  commands  the  '575 
"transmitter"  (again  derived  from  the  '1553A  command  word)  to  accept  data. 
Groups  of  two  16-blt  words  are  concatenated  by  the  DEB  into  a single 
32-blt  ARINC  575  word  and  transmitted  over  the  outgoing  '575  bus. 

The  software  resident  in  the  '1553A  bus  controller  performs  a number 
of  Jobs.  At  start-up,  a comounlcatlons  check  is  made  of  the  two  DEB's 
and  the  '1553A  bus.  When  the  communications  link  has  been  validated,  the 
software  ciimiunds  RT-to-RT  transfers  between  the  two  DEB's,  takes  a copy 
of  the  data  transferred,  puts  the  data  into  ASCII  format  and  transmits 
the  data  to  the  Hazeltlne  CRT  display.  Each  RT-to-RT  transfer  consists 
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MTA  BUS  DlFf€KNCES 


Table 


of  • 20-word  (1^0  ARINC  575  word*)  and  occurs  svery  58  ma.  Data 

ara  aanc  to  cha  CRT  and  rafraahad  avary  A64  aa. 

CONSBQUBWCtS  OF  DESIGN 

Tha  DEB  vaa  daalgned  to  hava  no  Intelllgenca.  Operation  la  In  reac- 
tion to  activity  over  tha  '575  bus  or  to  cniianda  sent  over  the  '1553A  bus. 
This  approach  Mda  It  possible  to  build  and  debug  the  DEB  within  a very 
short  aaount  of  tlae.  There  are.  however,  soae  operations  an  Intelligent 
Interface  could  perfom  that  the  present  DEB  does  not  perfora.  In  the 
present  setup,  the  bus  controller  software  must  Identify  each  '575  word 
before  reformatting  for  the  CRT  display.  An  Intelligent  Interface  could 
recognise  the  labels  of  Incoalng  ARINC  575  data.  This  Information  could 
either  be  transmitted  to  the  bus  controller  or  the  data  could  be  arranged 
In  a preset  order,  thus  relieving  the  bus  controller  software  of  one  task. 

Parity  checking  Is  used  on  all  '575  data  except  BCD  encoded  trords. 
Rather  than  have  no  error  detection  at  all,  the  DEB  checks  for  odd  parity 
and  rejects  all  tK>rda  with  even  parity.  Because  of  this,  the  DEB  throws 
out  many  "BCD  Altitude"  %rords  In  the  demonstration  setup  (see  Figure  2). 
Other  Interfaces  could  be  made  to  recognise  the  labels  of  BCD  encoded 
%ford8  and  not  reject  them  for  even  parity  or  perhaps  not  check  for 
parity  at  all. 

The  DEB  as  designed  Is  highly  dependent  on  the  '1553A  update  rate. 
When  the  bus  controller  does  not  take  data  fast  enough,  new  data  Incoalng 
on  the  ARINC  575  bus  Is  Ignored  and  lost.  If  the  bus  controller  causes 
data  to  be  transferred  to  a DEB  too  fast,  some  siessages  may  be  lost  since 
the  buffers  will  fill  up.  In  either  case,  this  interface  design  can  cause 
new  data  to  be  discarded  In  favor  of  old  data.  A number  of  solutions  for 
this  problem  exist  Including  extra  buffering.  Intelligence,  etc.,  but  were 
not  considered  worth  the  time  and  effort  required  In  light  of  the  objec- 
tives of  this  project.  The  "easiest"  solution  was  used,  namely  not  allow- 
ing the  problem  to  occur.  The  data  rate  from  the  air  data  computer  was 
measured  and  used  to  determine  the  rate  of  transfer  over  '1553A.  This 
solved  the  potential  problem  In  our  simple  demonstration  setup,  but  may 
be  Inadequate  for  more  complex  systems. 

CONCLUSIONS/LESSONS  LEARNED 


The  DEB  was  designed  In  the  easiest  and  quickest  manner  possible. 

This  agreed  with  the  project  objectives  which  did  not  necessarily  Include 
an  elegant  or  fllghttrorthy  design.  Since  a general  purpose  MTU  was  used, 
many  Inefficiencies  exist  In  the  areas  of  buffering,  data  massaging,  and 
handshaking  within  the  DEB.  A design  from  scratch,  although  more  efficient, 
would  have  taken  too  long.  Note  one  Important  fact:  the  DEB  was  designed 
as  a separate  unit  only  for  this  demonstration.  In  an  aircraft,  these 
Interfaces  would  normally  not  require  a separate  LRU. 


575/J553  CONPATIIILITY  TEST 


'V  « A 1 ' W 


Each  bus  syst«m  carries  along  a certain  amount  of  overhead  In 
addition  to  the  transmitted  data.  This  overhead  Includes  such  Items  as 
labels,  command  and  status  words.  Interword  or  Intermessage  gaps,  parity 
bits,  etc.  In  the  demonstration  system  tne  entire  ARINC  575  word  as 
received  Is  transmitted  over  '1553A.  Overheads  Including  the  label, 
sign  status  matrix,  and  parity  originating  In  the  '575  bus  are  carried 
over  and  added  to  the  load  carried  by  '1553A.  The  MIL-STn-1553A  bus 
handled  the  load  easily  In  this  demonstration,  but  a more  heavily  loaded 
bus  might  run  Into  difficulty.  Stripping  unnecessary  bits  from  a word 
and  packing  words  together  could  be  done  It  a more  efficient  transmission 
were  required.  If  this  were  done,  however,  extra  Intelllgence/sof tware 
would  be  required  at  the  receiving  end. 

This  Interface  design  achieved  Ito  purpose.  The  DEB  successfully 
allows  communication  between  an  ARINC  575  bus  and  a MIL-STD-1553A  bus. 
Design  Inefficiencies  exist,  but  no  serious  Interfacing  problems  were 
encountered.  Through  the  process  of  building  the  DEB,  ENA  engineers 
learnei.  about  ARINC  575  and  found  that  only  a relatively  simple  design 
was  required  to  Interface  the  two  bus  systems. 
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BUS  CONTROLLER  SOFTWARE  IMPLEMENTATION 


Thomas  L.  Zawodny 
ASD/ENAIA/(SEAFAC) 

Wright  Patterson  AFB,  OH  45433 


ABSTRACT 


This  paper  deals  with  the  complexity  of  impleroentinc 
the  bus  control  function  into  a system.  After  defining  ti.. 
bus  control  function,  various  bus  controller  designs  are 
examined  with  emphasis  on  the  software  requirements  of  each. 
General  performance  type  considerations  are  discussed 
leading  to  the  conclusion  that  definition  of  the  bus  control 
function  is  a system's  level  problem. 
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THE  BUS  CONTROL  FUNCTION 
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Continuing  advcmces  in  the  state-of-the-art  in  digital 
electronics  are  causing  significant  impact  on  the  numbers 
of  avionics  equipment  being  proposed  for,  and  implemented 
into,  future  and  existing  weapons  systems.  Entire  sub- 
systems such  as  stores  management,  fire  control,  and 
navigation  are  being  designed  with  embedded  minicomputers, 
and/or  microprocessors  in  addition  to  digital  electronic 
components.  Digital  electronics  is  coming  of  age  in 
avionics ! 

New  systems,  and  old  system  updates,  reveal  an  increas- 
ing data  interdependence  between  subsystems,  sensors,  and/or 
"functions".  Interchange  and  transfer  of  much  of  these  data 
between  "units"  is  being  accomplished  via  the  multiplex 
data  bus.  Controlling  the  flow  of  these  data  over  the  data 
bus  is  the  function  of  the  bus  controller. 

HARDWARE/SOFTWARE  CONTINUUM 

The  design  and  implementation  of  a bus  controller 
generally  embodies  a blending  of  hardware  and  software; 
hardware  for  its  inherent  reliability  and  software  for  its 
attendant  flexibility.  During  the  initial  design  phase 
conflicts  may  ensue  between  hardware  and  software  designers 
when  a simplification  by  one  causes  complication  for  the 
other.  Typically,  though,  the  hardware  design  is  completed 
first  and  any  resulting  complications  or  deficiencies  are 
left  for  software  to  resolve.  The  degree  of  software 
needed  to  implement  the  bus  control  function  (message  sequence 
and  timing)  will  depend  on  the  basic  hardware  approach  to 
the  system  architecture. 

Let  us  examine  three  candidate  families  of  bus 
controller  designs  and  highlight  the  software  needed  to 
implement  each. 

A.  Programmed  Hardware  - See  Figure  1.  In  this  bus 
controller  design,  the  function  to  be  performed  is  pre-deter- 
mined  and  programmed  onto  ROMs  or  PROMs.  The  circuitry 
within  the  bus  controller  accesses  these  (P) ROMs  and  initiates 
the  data  flow  across  the  bus  to  the  required  units  (remote 
terminals).  When  the  function  to  be  performed  changes  (i.e. 
when  the  system  requirements  change),  (P) ROMs  with  the  new 
schedule  of  data  transfers  are  programmed  to  replace  those 
existing  within  the  bus  controller.  The  software,  then,  is 
mainly  limited  to  that  necessary  for  programming  of  the  (P)ROMs. 
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FIGURE  1.  PROGRAMMED  HARDWARE  BUS  CONTROLLER 


FIGURE  2.  PROGRAMMABLE  HARDWARE  BUS  CONTROLLER 


FIGURE  3.  PROCESSOR-COUPLED  BUS  CONTROLLER 


B.  Prograunmable  Hardware  - See  Figure  2.  This  bus 
controller  design  is  essentially  the  same  as  the  programmed 
hardware  bus  controller  discussed  above.  The  difference  is 
that  the  mission  computer,  or  some  knowledgeable  processor, 
programs  the  memory  of  the  bus  controller.  The  bus  controller 
circuitry  then  repetitively  steps  through  the  "prograim"  thus 
controlling  the  data  flow  between  the  remote  terminals.  The 
software  requirement  is  that  needed  within  the  mission 
computer  to  generate  the  bus  controller  "program" . 

C.  Processor-Coupled  Bus  Controller  - See  Figure  3. 

In  this  configuration,  the  bus  controller  is  linked  to  a 
processor  which  executes  a software  program  to  oversee  the 
bus  control  function.  This  processor  may  be  dedicated  to 
the  bus  control  function  or  it  may  have  additional  processing 
requirements.  The  software  complexity  to  implement  this  bus 
controller  design  is  totally  dependent  on  the  sophistication 
of  the  bus  controller  circuitry  itself.  That  is,  the  more 
primitive  the  circuitry,  the  greater  the  software  interaction 
required  to  process  a command  or  message.  Three  examples 

of  this  type  of  bus  controller  will  illustrate  this  point. 

1.  Single  Word  - This  most  primitive  of 
processor-coupled  bus  controllers  requires  software  inter- 
action for  each  and  every  word  of  the  message.  Though  a 
software  routine  can  be  written  to  "force  feed"  words  to 
the  bus  controller,  the  message  processing  burden  remains 
in  the  software. 


2.  Single  Message  - This  "second  generation"  bus 
controller  has  the  capability  of  processing  one  complete 
message  at  a time.  The  processor  software  sends  the  starting 
memory  address  of  the  message  to  the  bus  controller  which, 

in  turn,  performs  a direct  memory  access  (DMA)  into  the 
processor  memory  for  the  required  message.  The  bus  trans- 
action is  then  processed  under  direct  control  of  the  hardware, 
which  signals  the  software  when  the  activity  finishes.  The 
software  is  then  left  to  examine  the  returned  transaction 
status  information  (status  word,  etc.)  in  order  to  insure 
that  the  message  was  indeed  processed  as  requested.  In  this 
bus  controller,  the  software  interaction  is  lessened  by  the 
added  capability  within  the  hardware. 

3.  Table  Driven  - See  Figure  4.  This  "third 
generation"  bus  controller  features  enhanced  hardware  to 
allow  processing  of  more  than  one  message  with  a single 
software  action.  Numerous  messages  are  structured  and  their 
starting  addresses  are  placed  into  a table  in  memory.  To 
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initiate  processing  of  these  messages,  the  starting  address 
of  the  table  of  addresses  is  passed  to  the  bus  controller. 

The  bus  controller  continues  DMAs  into  the  processor  memory, 
stepping  through  the  table  of  addresses  until  either  all 
messages  are  processed  or  until  an  error  occurs.  An 
activity-complete  signal  and  individual  transaction  status 
words  are  returned  to  the  software  for  examination,  just  as 
in  the  single  message  bus  controller.  Though  the  software 
is  simplified  by  the  added  complexity  in  the  hardware, 
considerable  software  activity  may  still  be  required  for 
those  applications  where  message  structure  or  table  organi- 
zation must  vary  during  the  performance  of  the  bus  control 
function.  The  method  by  which  the  last  message  in  the  table 
is  recognized  is  defined  by  the  particular  design. 

IMPLEMENTING  THE  BUS  CONTROLLER  INTO  THE  SYSTEM 

With  a brief  overview  of  bus  controller  design  behind 
us,  we  can  begin  to  examine  a definition  of  the  bus  control 
function;  i.e.,  the  sequence  and  timing  necessary  to  satisfy 
the  system  data  flow  requirements.  Two  major  areas  need  to 
be  considered  in  defining  the  bus  control  function:  the 
peculiarities  and  interrelations  of  the  subsystems  on  the 
bus,  and  the  system  requirements  for  timing,  redundancy,  and 
error  handling. 

'i 

A.  System  Requirements.  The  first  major  area  to 
consider  when  implementing  the  bus  control  function  is  the 
overall  system  requirements.  These  requirements  define 
what  transactions  are  to  occur  between  which  remote  terminals 
and  at  what  rates.  Complications  occur  when  multiple  bus 
transactions  from  various  sources  are  required  to  satisfy 
the  data  needs  of  a subsystem  and  the  data  availability  rates 
do  not  match.  A system  timing  consideration  is  the  inter- 
ference between  processing  tasks  resident  in  a shared 
processor-coupled  bus  controller  and  the  bus  control  message 
queueing  tasks.  An  overview  of  the  total  data  flow  require- 
ments for  both  processor  and  system  is  needed  to  allow  a 
logical  sequencing  of  tasks  to  be  structured.  This  requires 
an  in-depth  knowledge  of  each  subsystem's  requirements  and 
timing  along  with  the  processor's  requirements  and  capabilities. 

Another  system-level  requirements  consideration  is 
the  handling  of  errors.  Should  errors  be  reported  to  the 
operator  or  executive;  if  so,  how  and  when?  should  the  bus 
controller  be  smart  enough  to  retry  an  offending  message;  if 
so,  how  many  retries?  Bus  transaction  errors  (no  response. 
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bad-sync,  etc.)  are  easily  detected  by  hardware.  However, 
an  error  also  occurs  when  the  data  "received"  does  not  match 
the  data  "sent".  Should  this  error  be  anticipated  and 
corrected,  and  if  so,  how? 

A last  systems-level  consideration  is  redundancy, 
of  both  buses  and  bus  controllers.  Should  traffic  occur  on 
both  buses  "simultaneously"  or  should  only  one  be  active? 

In  a redundant  bus  controller  system,  how  is  failure  of  the 
primary  controller  detected,  who  detects  it,  and  how  is  the 
back-up  activated? 

B.  Subsystem  Peculiarities.  Though  it  is  desireable 
for  the  various  remote  terminals  on  the  bus  to  possess 
identical  capabilities,  a particular  system  may  not  have 
that  luxury,  particularly  in  system  updates.  For  example, 
does  the  readiness  of  a remote  terminal  need  to  be  verified 
before  initiating  a bus  transaction?  Some  designs  provide 
this  feature  while  others  do  not.  An  exchange  of  data 
between  two  remote  terminals  will  be  complicated  if  one  or 
both  have  only  receive/transmit  capabilities  as  opposed  to 
terminal-to-terminal  transfer. 

CONCLUSIONS 


The  implementation  of  a bus  controller  function  is  a 
highly  complex  problem  requiring  resolution  at  the  systems 
design  level. 

The  system  design  process  generally  begins  by  defining 
the  purpose  of  the  system  and  by  specifying  the  system 
performance  requirements.  When  the  system  requirements  have 
been  defined,  various  subsystems  are  proposed  to  meet  them. 
Further  detailed  stuuy  refines  the  definition  of  the  sub- 
systems, including  the  interdependent  data  flow  and  timing 
requirements  of  each.  The  combination  of  these  requirements 
becomes  the  definition  of  the  bus  control  function.  The 
realization  of  this  function  then  becomes  the  design  effort 
of  hardware  and  software  combined. 

It  is  important  to  realize  the  pivotal  role  the  bus 
controller  plays  within  a system.  The  capabilities  of 
various  subsystems  are  multiplexed  for  increased  system 
flexibility  and  more  centralized  control.  The  bus  control 
function  can  be  viewed  as  the  subsystem  integrator  or  as  the 
"glue"  that  holds  the  system  together. 
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ABSTRACT 

This  paper  describes  the  MATE  System  program  and 
discusses  the  multiplexing  approaches  that  will  be 
examined.  The  MATE  System  program  output  will  consist 
of  four  "guides"  containing  standards,  specifications, 
manuals,  handbooks,  and  procedures.  Included  in  these 
guides  will  be  a set  of  interface  standards  that  makes 
maximum  use  of  readily  available  test  equipment  modules 
and  standard  data  buses.  The  elements  to  be  considered 
in  developing  these  interface  standards  are  described, 
and  the  principal  characteristics  of  several  candidate 
bus  standards  are  discussed. 

A.  THE  MATE  PROGRAM 

1 . General 


i 

i 


The  Modular  Automatic  Test  Equipment  (MATE)  program 
has  been  conceived  by  the  Air  Force  as  a means  of  pro-  i 

viding  effective  support  of  future  avionics  equipment  i 

at  the  lowest  possible  life-cycle  cost.  This  program  has  f 

been  divided  into  several  segments,  the  first  of  which,  i 

the  MATE  System  program,  was  started  in  July  of  this  year,  j 

and  will  be  completed  in  December  1980.  The  next  segment 
of  the  program  will  improve  and  refine  the  concepts  devel- 
oped during  the  first  segment,  and  will  implement  the  re- 
sulting improved  concepts  in  the  form  of  a prototype  MATE 
system. 
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The  specific  objectives  of  the  overall  program  are 
defined  as  follows: 

• Reduce  life-cycle  costs  of  weapon  system 
support,  including  costs  of  automatic  test 
equipment  (ATE) • 

• Reduce  the  number  of  different  types  of  ATE 
required. 

• Improve  operational  utility,  test  efficiency, 
and  management  of  ATE. 

• Improve  ATE  procurement  practices. 

These  objectives  are  guiding  the  activities  of  the 
current  MATE  System  program. 

2.  MATE  System  Program  Outputs 

The  end  products  of  the  MATE  System  program  will  con- 
sist of  four  guides,  each  of  which  will  include  standards, 
manuals,  handbooks,  and  management  procedures.  In  each 
guide  there  will  be  references  to  the  other  guides,  to 
data  systems,  and  to  other  standards  that  form  an  integral 
part  of  the  design  comcept.  The  four  guides  are  titled: 
Electronic  Test  Equipment  Acquisition  Guide,  MATE  Develop- 
ment Guide,  Avionics  Testability  Design  Guide,  and  Produc- 
tion/Operational Guide. 

The  Electronic  Test  Equipment  Acquisition  Guide  will 
provide  information  for  acquiring  effective  low-cost 
support  systems.  This  information  will  define  responsi- 
bilities and  decision  points  for  equipment  acquisition, 
and  will  include  procedures  for  making  life-cycle  cost 
trade  studies  and  for  matching  test  system  changes  to 
weapon  system  changes . 

The  MATE  Development  Guide  will  provide  information 
for  the  design  of  MATE  test  configurations  to  meet  specific 
performance  requirements.  This  guide  will  cover  all 
aspects  of  the  system,  including  hardware,  software,  and 
human  interfaces,  and  will  be  based  on  requirements  of 
avionics  units  to  be  tested  in  accordance  with  the  recom- 
mended maintenance  plan. 
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The  Avionics  Testability  Design  Guide  will  provide 
guidance  and  checkpoints  to  the  avionics  design  engineers 
for  incorporating  design  features  that  facilitate  testing 
the  units. 

The  MATE  Production/Operational  Guide  will  contain 
information  required  for  using  MATE  test  systems  to  main- 
tain configuration  control  and  to  establish  feedback  for 
keeping  MATE  systems  responsive  to  operational  needs. 

These  guides  will  provide  the  technical  tools  and 
procedures  for  acquisition  management  of  avionics  support, 
and  for  development,  design,  production,  and  logistics 
support  of  future  automatic  test  systems. 

3.  Program  Tasks 

The  system  development  program  is  divided  into  three 
principal  phases:  the  Survey/Study  Phase,  Study/Verifica- 
tion Pliase,  and  Demonstration  Phase. 

The  Survey/Study  Phase  includes  the  following  tasks: 

• Perform  surveys  of  operational  sites,  test 
equipment  manufacturers'  facilities,  and 
literature  pertaining  to  all  aspects  of 
ATE. 

• Reduce  data  obtained  from  the  surveys. 

• Perform  initial  studies  and  analyses  of 
hardware,  software,  human  interfaces, 
testability,  and  avionics  support 
system  acquisition. 

• Conduct  design  studies  to  synthesize  and 
analyze  candidate  system  designs. 

• Formulate  optimal  support  equipment 
acquisition  approaches  and  procedures. 

• Produce  draft  copies  of  four  program  end 
product  guides. 
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The  Study/Verif ication  Phase  includes  the  following 
tasks : 

• Verify  the  content  of  the  four  draft  guides, 
where  necessary,  through  procurement  and 
phototyping  of  hardware,  software,  or 
documentation  items  needed  to  verify 
advanced  design  concepts. 

• Prepare  final  draft  copies  of  the  four  guides. 

• Develop  a test  and  evaluation  plan  for  the 
Demonstration  Phase. 

The  Demonstration  Phase  includes  the  following 
tasks,  which  will  be  accomplished  through  analysis, 
simulation,  and  test. 

• Demonstrate  how  use  of  the  four  guides 
would  have  enhanced  testability  of 
selected  avionics  units. 

• Use  the  guides  to  define  a test  system  for 
support  of  15  avionics  units  selected  by 
the  Air  Force. 

• Use  the  guides  to  design,  fabricate,  operate, 
and  evaluate  four  test  station  configurations 
based  on  requirements  of  four  avionics  units 
selected  by  the  Air  Force;  and  demonstrate 
fault  isolation  and  modularity  of  the  test 
stations . 

• Update  the  four  guides,  as  necessary,  based 
on  the  results  of  the  demonstration. 

B.  INSTRUMENTATION  CONCEPTS 

The  study  of  various  candidate  support  system 
approaches  during  the  first  two  phases  of  the  MATE  System 
program  will  include  developing  an  optimum  set  of  inter- 
face standards  that  make  maximum  use  of  available  military 
and  commercial  test  equipment.  Such  interface  standards 
will  permit  configuring  of  modules  from  various  manufac- 
turers into  automatic  test  systems.  Also,  these  standards 


will  permit  substitution  of  modules  from  different  manu- 
facturers for  testing  identical  types  of  avionics  units. 
They  will  also  permit  reconfiguring  the  system  for  testing 
different  types  of  avionics  units.  The  standards  will  be 
adaptable  to  new  avionics  and  test  equipment  designs,  and 
will  be  compatible  with  industry  standards  wherever 
possible. 

The  relationships  among  the  elements  to  be  considered 
in  developing  these  interface  standards  are  illustrated 
in  Figure  1,  which  shows  a simplified  block  diagram  of  a 
typical  test  station.  This  station  contains  a controller 
(which  may  be  a digital  computer  and  peripherals) , inter- 
face adapters,  multiple  test  modules  (stimulus  and  meas- 
urement test  instruments) , the  unit  under  test,  and  the 
interconnecting  buses.  Multiplexing  of  data  is  required 
to  provide  control  and  response  signals  between  the  con- 
troller and  the  various  test  modules,  as  well  as  between 
the  test  modules  themselves. 

The  development  of  these  interface  standards  will 
include  examination  of  the  following  items. 

• Requirements  of  avionics  units  to  be  tested 

• Human  interface  requirements 

• Controllers  and  test  equipment  modules 
capable  of  meeting  these  requirements 

• Different  types  of  multiplex  data  buses, 
including  both  standardized  and  unstandarized 
types 

• Interface  adapter  designs  needed  to  match 
the  controller  and  test  modules  to  the  bus 
characteristics 

These  items  are  discussed  in  the  following  paragraphs. 

The  requirements  of  avionics  units  to  be  tested  will 
be  obtained  from  the  results  of  the  surveys  and  studies 
conducted  during  the  first  phase  of  the  program.  All 
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DOTTED  ARROWS 
INDICATE  POTENTIAL 
CONNECTIONS 
DEPENDING  ON 
EQUIPMENT 
COMPATIBILITY  AND 
MIX  OF  BUSES 
INCLUDED  IN  TEST 
STATION. 

•ADAPTER  WILL  NOT 
BE  REQUIRED  FOR 
SOME  MODULES. 


Figure  1.  Typical  Test  Station  Interconnections 


classes  of  existing  and  proposed  avionics  units  will  be  in- 
cluded (e.g.,  digital,  analog,  r-f,  microwave,  and  optical, 
with  many  types  in  each  class) . 

The  human  interface  requirements  will  also  be  obtain- 
ed from  the  surveys  and  studies.  They  will  influence  the 
choice  of  candidate  hardware,  software,  and  data  bus 
elements  by  defining  display,  control,  and  equipment-han- 
dling features. 

Controllers  and  test  equipment  modules  available  for 
meeting  these  requirements  may  differ  in  their  interface 
characteristics.  Typical  differences  among  those  elements 
can  be  summarized  as  follows. 

• The  data  type  may  be  completely  serial 
or  combined  serial  and  parallel. 

• Data  rates  may  vary  from  zero  to  several 
megabits  per  second. 

• Data  formats  may  include  various  methods  of 
synchronization,  addressing,  data  organization, 
coding,  and  error  chocicing. 

• The  number  and  timing  relationships  of  control 
signals  for  handshaking  and  interface  manage- 
ment may  vary. 

• Signal  characteristics  may  differ  in  am^ilitude, 
waveshape,  or  polarity. 

• Source  or  load  characteristics  may  vary  in 
impedance,  allowable  voltage  limits,  or 
sensitivity  to  noise. 

• Mechanical  features  may  vary,  sucli  as 
connector  types,  connector  locations,  or 
cabinet  dimensions. 

The  interface  adapters,  interconnecting  buses,  and 
controller  software  must  acr'ommodate  these  differences 
between  the  various  candidate  controllers  and  test  equip- 
ment modules,  and  must  provide  optimum  test  capability. 
Thus,  in  configuring  various  hypothetical  ATF.  systems  as 


part  of  the  MATE  interface  standards  development  process, 
trade-offs  among  the  following  candidate  choices  must  be 
considered; 


• Number  of  different  types  of  avionics 
units  accommodated 

• Number  of  different  controllers  and  test 
modules 

• Complexity  and  number  of  interface  adapters 

• Number  of  different  types  of  buses  and 
number  of  buses  of  the  same  type 

• Degree  of  data  processing  at  the  test 
module  to  reduce  bus  data  transmission 
rates 

• Degree  of  modification  of  standard  test 
equipment  modules  to  reduce  number  or 
complexity  of  adapters 

• Level  of  test  equipment  testability  and 
self-test 

The  goal  of  this  trade  study  is  to  define  a set  of 
interface  standards  that  provide  optimum  mixes  of  adapters, 
buses,  software,  controllers,  and  test  equipment  modules 
for  all  foreseeable  test  situations. 

C.  CANDIDATE  DATA  BUSES 

1 . General 

In  order  to  accommodate  the  differences  in  data  rates, 
and  to  permit  a wide  choice  of  controllers,  test  modules, 
and  interface  adapters,  a number  of  different  bus  types 
will  be  considered  for  inclusion  in  the  MATE  interface 
standards.  The  significant  characteristics  of  several 
candidate  buses  are  discussed  in  the  following  paragraphs. 

2.  IEEE  Standard  488-1975 

The  IEEE  Standard  Digital  Interface  for  Programmable 
Instrumentation  (IEEE  Std.  488-1975*)  has  gained  wide  ^ 


♦Also  known  as  ANSI  MC  1.1-1975,  or  HP-IB,  or  GPIB. 
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acceptance  in  the  test  equipment  industry.  The  intended 
use  of  this  bus  standard  is  to  define  the  interconnection 
of  both  programmable  and  nonprogrammable  devices  assembled 
as  an  instrumentation  system. 

The  principal  features  of  this  bus  include:  capability 
of  handling  up  to  15  devices  on  a single  bus;  transmission 
of  data  as  a sequence  of  8-bit  bytes  on  8 wires  (bit- 
parallel/by  te-serial  ) ; transmission  of  control  signals  on 
8 wires;  and  operation  at  a maximum  data  rate  of  one  mega- 
byte per  second  over  short  distances. 

This  bus  standard  is  expected  to  be  compatible  with 
most  of  the  applicable  types  of  test  equipment  modules  and 
controllers  that  will  be  available  for  implementation  on 
ItATE. 

3.  EIA  Standards  RS-232-C  and  RS-449 

EIA  Standard  RS-232  has  been  the  accepted  standard  for 
interfacing  serial  data  communication  equipment  and  com- 
puters with  data  terminals  (such  as  teletypes  and  CRTs) 
for  many  years.  The  newer  EIA  Standard  RS-449  together 
with  EIA  Standards  RS-422  and  RS-423  are  intended  to  grad- 
ually replace  RS-232-C  (the  latest  revision  of  RS-232) . 

The  RS-232-C  standard  specifies  transmission  of  data 
serially  between  two  devices  at  rates  up  to  about  20,000 
bits  per  second.  Fourteen  control  signals  are  defined, 
but  fewer  are  required  in  most  applications. 

The  combined  RS-449,  RS-422,  and  RS-423  standards  liave 
been  issued  to  specify  new  electrical  characteristics  and 
to  define  several  new  interface  functions.  The  new  electri- 
cal characteristics  accommodate  advances  in  integrated  cir- 
cuit design,  reduce  crosstallt,  permit  greater  se;\tiation 
of  equipment,  and  permit  higher  data  signaling  rates  (up 
to  2 megabits  per  second  maximum) . 

4.  MIL-STD-1553A 

The  MIL-STD- 1 553A  multiplex  data  bus  standard  defines 
the  requirements  for  data  communications  among  various 
avionics  units  within  an  aircraft.  Because  botli  existing 
and  future  avionics  systems  will  be  compatible  with  this 
bus,  it  is  expected  that  this  interface  will  be  useful  for 
test  purposes.  For  example,  the  test  equipment  controller 
could  feed  data  representing  simulated  sensor  valvu's  to  the 
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digital  computer  in  a unit  under  test  and  receive  resulting 
outputs  from  the  unit.  The  bus  might  also  be  used  with  test 
equipment  modules  designed  to  operate  with  this  interface. 

5.  IEEE  Standards  583/595/596  (CAKAC) 

The  CAMAC  interface  standard  has  been  used  in  nuclear 
laboratories  and  process  control  industries  for  several 
years.  This  standard  defines  in  detail  the  mechanical  con- 
struction of  a rack-mounted  chassis  called  a "crate"  which 
houses  a controller  and  up  to  23  test  modules  or  adapters. 

It  also  defines  methods  of  interconnecting  multiple  crates. 

The  bus  provides  83  wires  within  the  crate,  including 
24  data  wires  in  each  direction.  Data  may  be  transmitted 
between  crates  in  either  serial  or  parallel  form  at  rates 
up  to  5 megahertz. 

6.  Other  Interface  Candidates 

Types  of  interfaces  other  than  those  summarized  in  the 
preceding  paragraphs  may  be  included  in  the  interface  stan- 
dards being  developed  on  the  MATE  program.  For  example, 
if  data  rates  are  too  high  to  be  conveniently  accommodated 
by  these  buses,  or  by  multiple  sets  of  these  buses,  a con- 
troller that  includes  a computer  having  a direct  memory 
access  (DMA)  channel  may  be  required. 

The  decisions  regarding  which  buses  to  include  in  the 
MATE  interface  standards  will  result  from  consideration 
of  the  various  existing  and  future  data  requirements,  the 
characteristics  of  available  equipment,  and  the  feasibility 
of  distributing  processing  functions. 

D.  CONCLUSIONS 

The  multiplexing  aspects  of  the  MATE  System  program 
require  the  integration  of  test  equipment  hardware  and 
software  elements  with  the  characteristics  of  various  data 
buses  to  provide  a set  of  useful  interface  standards.  These 
standards  must  be  flexible  enough  to  meet  requirements  of 
future  test  equipment  and  avionics  equipment,  and  yet  pro- 
vide sufficient  detail  for  assuring  successful  interchange- 
ability of  modules.  The  Air  Force  has  directed  that  all 
aspects  of  this  study  be  examined  from  a systems  viewpoint, 
thus  maximizing  the  probability  that  these  requirements  will 
be  met. 
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ABSTRACT 

This  paper  advocates  a more  sophisticated  distributed 
processinsi  approach  than  is  currently  used  in  MIl.-STD- 1 55 JA. 
Rather  than  a central  bus  controller,  ilistributed  control 
with  "smart"  terminals  can  provide  a hiqher  decree  of  reli- 
ability and  adaptiveness  to  avionics  systems.  A new  pro- 
vision in  the  proposed  MI L-STD- 155 JB  opens  this  possibility 
by  defininq  a dynamic  bus  allocation  protocol.  A candidate 
approach  for  distributed  control  is  presented. 

DISTRIBUTED  PROCESSING  TRENDS  IN  AVIONICS 

A recent  study  indicates  that  distributed  processinq 
will  be  the  most  dynamic  seqment  of  the  computer  industry 
in  1981^.  The  underlyinq  force  behind  this  chanqe  is,  of 
course,  the  microprocessor  revolution.  Low  cost  distrilnited 
intelliqence  will  have  a stronq  influence  on  system  desiqn 
for  many  years  to  come.  This  influence  is  evident  in  re- 
cently developed  avionics  systems.  The  F-15  and  F-lb  have 
several  processors  dedicated  to  separate  functions  such  as 
naviqation,  radar,  and  fire  control,  and  are  interconnect eil 
by  a 1 MHz  time  division  multiplex  data  bus.  This  is  in 
contrast  to  aircraft  desiqns  of  the  19b0’s  which  qenerally 
have  one  larqe  computer  and  no  multiplex  data  bus.  The 
distributed  processinq  trend  is  expected  to  continue  in 
future  aircraft  with  iarqe  numbers  of  microcomputers  per- 
forming dedicated  functions  in  an  interconnected  network. 
These  processors  will  operate  nearly  autonomously  and  com- 
municate via  a shared  resource  - the  avionics  data  bus. 


A key  issue  in  the  design  of  future  avionic  distributed 
processing  systems  will  be  how  to  control  allocation  of  the 
data  bus  and  processing  resources.  In  systems  with  one  com- 
puter, the  central  control  concept  obviously  applies.  This 
concept  can  even  be  extended  to  systems  with  several  compu- 
ters by  partitioning  software  tasks  among  processors  in 
advance,  and  by  assigning  one  as  the  master  bus  controller. 
This  technique  forms  the  basis  of  MIL-STD-1553  and  1553a2  in 
which  the  bus  control  computer  is  programmed  in  advance  with 
all  synchronous  bus  transmissions.  The  central  control  con- 
cept works  well  in  an  avionics  system  with  several  minicom- 
puters and  "dumb"  remote  terminals.  However,  the  authors 
feel  it  is  a suboptimal  approach  in  future  designs  which 
will  be  characterized  by  smaller,  more  numerous  processors 
and  "smart"  remote  terminals.  New  approaches  have  been 
developed  in  which  responsibility  for  data  bus  and  resource 
allocation  is  shared  by  multiple  computers.  These 
approaches  have  been  collectively  termed  "distributed  con- 
trol," and  have  potential  to  provide  many  advantages,  most 
notably  adaptiveness. 

DISTRIBUTED  CONTROL  CAN  BE  ADAPTIVE 

The  emphasis  in  military  avionics  in  the  future  will  not 
be  in  simply  interfacing  equipment,  but  in  achieving  better 
overall  integrated  performance.  This  is  motivated  by  the 
need  to  obtain  better  reliability  with  increasingly  complex 
equipment.  Direct  redundancy  is  a "brute  force"  approach 
which  aggravates  size,  weight,  and  cost  constraints.  What 
is  needed  is  a more  sophisticated  form  of  integration  among 
avionics  equipment  which  has  more  adaptive  work  around  and 
back-up  capabilities. 

Distributed  control  is  a technology  which  has  great 
potential  for  providing  integrated  avionics  systems  with 
better  flexibility  and  tolerance  to  faults.  While  it  will 
generally  lead  to  a more  complex  architecture,  it.  can 
actually  reduce  hardware  size  and  weight  by  eliminating 
the  need  for  a central  control  computer. 

Other  advantages  can  be  brought  to  avionics  networks 
employing  distributed  control.  "Smart"  terminals  can  link 
up  directly  to  desired  interfaces  without  the  need  for 
centralized  apriori  interface  definitions.  This  adaptive 
modular  approach  would  simplify  equipment  interfacing,  as 
well  as  government  contracting,  by  eliminating  third  party 
interface  control.  Optimized  interface  traffic  could  be 
determined  adaptively  in  flight. 
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This  interface  adaptability  can  be  utilized  to  improve 
reliability  with  a "fail  soft"  capability.  If  secondary 
sources  of  data  can  be  located  on  the  bus,  traffic  can  be 
rearranged  in  flight  to  support  its  use.  One  of  the  most 
powerful  ways  of  achieving  reliability  without  direct  re- 
dundancy is  to  perform  remote  processing  of  crucial  avionics 
functions.  To  achieve  this,  less  critical  processors  would 
have  to  be  reconfigured  with  back-up  programs.  These  remote 
programs  would  manipulate  critical  function  input/output 
(I/O)  over  the  multiplex  bus  providing  a degraded  back-up 
capability.  A Navy  study  has  suggested  bus  terminals  which 
can  directly  tie  into  the  equipment  I/O  to  support  this 
concept. ^ 

Needless  to  say,  supporting  I/O  control  over  the  bus 
would  radically  distort  the  optimum  data  traffic  on  the  bus. 
However,  an  adaptive  bus  control  could  reconfigure  interface 
traffic  to  support  a wide  variety  of  these  back-up  conditions. 

A CANDIDATE  APPROACH  FOR  DISTRIBUTED  CONTROL 

To  be  sure,  adaptive  avionics  processing  and  interface 
control  for  the  avionic  bus  is  a desirable  objective.  The 
literature  abounds  with  distributed  processing  concepts  in 
all  levels  of  abstraction.  To  bring  this  theory  and  practice 
into  better  focus,  one  approach  for  adaptive  distributed  bus 
allocation  is  presented  in  this  paper.  It  is  based  on  recent 
work  at  Westinghouse  on  multi-processing.  The  proposed 
scheme  requires  that  four  basic  provisions  be  made  as  des- 
cribed below. 

1)  . Define  Dyneunic  Bus  Allocation  Protocol 

In  anticipation  of  distributed  processing,  MIL-STD-1553A 
provides  an  option  for  passing  bus  control  from  one  computer 
to  another.  As  of  this  writing,  the  proposed  MIL-STD-1553B 
defines  a specific  protocol  for  passing  control  which  includes 
"handshaking".  Consequently,  the  framework  exists  in  which 
to  develop  architectures  which  exploit  the  potential  advan- 
tages of  distributed  control,  while  maintaining  compatibility 
with  equipment  designed  to  MIL-STD-1553A  or  B.  This  general 
approach  is  quite .similar  to  that  proposed  in  1975  as  part  of 
the  IEEE  488  bu8.^  Very  little  use  has  been  made  of  this 
488  capability  to  date  because  of  the  lack  of  distributed 
operating  systems. 
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There  are  several  more  advanced  approaches  for  distri- 
buted bus  control  discussed  in  a recent  AFAL  report.^ 
Generally,  they  are  a radical  departure  from  the  command 
response  precept  of  1553  and  are,  therefore,  not  considered 
here.  However,  the  bus  contention  schemes  discussed  in  this 
report  should  be  considered  on  future  buses.  The  naturally 
adaptive  features  of  uncoordinated  bus  contention  could 
simplify  the  start-up  and  bus  allocation  requirements  des- 
cribed below. 


2)  . Initialization 

The  initial  coordination  of  an  associative  control 
scheme  must  be  given  special  consideration.  Since  there  is 
no  one  controller,  there  is  a distinct  ambiguity  during 
system  initialization.  The  easiest  approach  is  to  identify 
one  processor  as  the  initial  organizer  to  begin  the  associ- 
ative process.  Naturally,  in  the  event  of  initialization 
problems,  back-up  processors  must  be  prepared  to  intercede. 

3)  . Centralized  Data  Base 

A central  data  base,  such  as  a mass  memory,  would  be 
used  in  place  of  the  control  computer  for  system  bus  real 
time  control  and  coordination.  The  central  data  base 
would  be  composed  of  three  types  of  data: 

o Bus  Management  Data 

o Real  Time  Clock 

o Back-up  equipment  configurations 

Functionally,  the  central  data  base  provides  the  command 
sequence  among  controllers  with  a real  time  reference.  A 
central  data  base  can  also  serve  to  down-load  intelligence 
into  local  processing  elements  for  fail  soft  capability  as 
described  above. 


To  minimize  fault  dependency  on  a central  data  base, 
some  form  of  back-up  capability  must  be  included.  Critical 
data  could  be  replicated  in  the  "smart"  terminals  to  support 
back-up  communications  in  the  event  centrallized  bus  manage- 
ment data  were  not  available.  Further,  in  each  avionics 
subsystem  "hard"  programming  of  some  local  intelligence  must 
be  maintained  to  insure  a minimum  systems  capability. 


4).  Associative  Control  Algorithms 

Recent  work  at  Westinghouse  has  investigated  distributed 
control  techniques  for  multiprocessing. 6 Many  of  these  con- 
cepts are  also  applicable  to  decentralized  multiplex  bus  con- 
trol. In  a general  sense,  bus  time  allocation  is  directly 
analogous  to  task  scheduling  in  multiprocessing.  A central 
authority  can  stand  "off  line"  and  direct  traffic  (or  pro- 
cessing) . This  authoritative  approach  is  easy  to  understand 
and  visualize.  However,  the  more  efficient  architecture  is 
to  have  the  units  do  their  own  scheduling.  This  leads  to  a 
more  adaptive  structure  where  the  units  work  in  association 
with  each  other. 

Two  distinct  control  approaches  were  studied.  The  first 
was  a "one  time"  calculated  control  sequence  which  remains 
fixed  until  conditions  change,  such  as  a failure  or  mode 
switch.  Figure  1 shows  the  major  decisions  which  must  go 
into  the  optimum  control  sequence  lists.  The  associative 
controllers  would  jointly  establish  resources,  interface 
priorities,  and  timing  requirements  under  interim  control. 
This  overhead  for  calculating  a fixed  timing  sequence  on  the 
bus  is  obviously  very  small.  The  complex  optimization  and 
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Figure  1.  Calculating  an  Optimum  Control  Sequence 


resource  management  calculations  are  performed  only  once  per 
configuration.  Thereafter,  each  controller  merely  passes 
control  to  the  next  on  the  list  using  the  MIL-STD-1553B  dyan- 
mic  bus  allocation  protocol  after  the  agreed  upon  bus  control 
time.  If  the  bus  traffic  matches  that  projected  by  the  cal- 
culations, this  is  a highly  efficient  approach.  Because  it 
is  fixed,  however,  it  degrades  if  the  traffic  varies  signifi- 
cantly from  the  predicted. 

A second  distributed  control  approach  developed  in  the 
Westinghouse  study  was  "Dynamic"  bus  allocation.  Here,  the 
optimization  of  prioritized  bus  traffic  would  be  calculated 
"in-line"  with  each  bus  control  sequence.  Based  on  time  de- 
pendent interface  priorities,  control  would  be  passed  to  the 
next  most  important  controller,  again  using  the  MIL-STD-1553B 
dynamic  bus  allocation  protocol.  Figure  2 shows  how  dif- 
ferent types  of  interface  control  priority  characteristics 
could  be  managed.  "Hard" , as  well  as  "Soft" , interface 
timing  sequences  could  be  managed  through  this  distributed 
control.  Dynamic  interface  optimization  would,  indeed, 
require  more  overhead;  however,  it  would  be  much  more  res- 
ponsive to  real  time  bus  traffic  pattern  changes. 
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Figure  2.  Timed  Control  Priority 
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CONCLUSIONS 


Future  avionics  needs  for  increasing  capability  and 
reliability  argue  for  more  sophisticated  integration  of 
equipment.  The  recent  proposed  changes  in  MIL-STD-1553B 
further  defining  dynamic  bus  control  should  be  exploited  to 
allow  multiple  "smart"  terminals  to  -ontrol  the  bus.  The 
next  step  is  to  develop  adaptive  distributed  control  ap- 
proaches like  the  ones  presented  in  this  paper. 
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ABSTRACT 

Functional  partitioning  of  on-board  integrated  data 
acquisition,  processing  and  distribution  systems  can  have  im- 
pact on  cost,  reliability,  maintenance,  and  other  factors. 

If  data  processing  systems  are  to  be  partitioned  from  the  unit 
level  (i.e.  a box  containing  a number  of  modules)  to  the  module 
level  (e.g.  multiplexers,  A/D  converters,  memory  modules  ....), 
standard  electrical  Interfaces  and  standard  transfer  procedures 
must  be  established  between  the  different  modules. 

On  the  unit  level  the  serial  data  bus  acc.  to  MIL-STD-1553 
forms  the  data  highway  between  LRU's. 

Investigations  towards  appropriate  solutions  for  interfaces  and 
transmission  techniques  between  a large  number  of 

modules  have  resulted  in  the  development  of  a 
parallel  bus  as  the  dataway.  This  is  the  best  compromise  bet- 
ween flexibility,  cost, performance , complexity,  and  adapta- 
bility to  technical  innovations. 

For  a consequent  system  structure  the  partitioning  of  hardware 
and  software  is  of  the  same  importance.  Since  the  hardware  is 
well  structured  through  the  interface  specification  of  the 
serial  data  highway,  the  parallel  data  way  and  the  functional 
modules,  an  executive  and  high  order  real  time  language  compiler 
has  been  sucsessfully  applied  for  systematic  software  pro- 
duction . 
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1 . INTRODUCTION 


Higher  mission  requirements  of  aircraft  weapon  systems  are 
leading  continuously  to  Increased  performance  of  (Avionic-, 
Guidance  and  Control-)  Onboard  Electronic  Systems.  This  has 
led  to  a remarkable  increase  in  the  number  of  electronic 
systems  aboard  the  aircraft  and  to  an  extremely  large  in- 
crease in  complexity  and  cost  in  all  the  considered  phases 
(development,  production  and  mainly  in  the  life  cycle) . New 
structures,  systems  techniques  and  technologies  under  con- 
sideration have  to  have  the  potential  for  the  required  in- 
crease in  mission  capability  and  configuration  flexibility 
with  less  complexity,  cost,  crew  workload  and  cockpit  panel 
space . 


The  traditional  architecture  has  been  an  amalgamation  of 
nearly  autonomous  subsystems  for  all  different  functions,  each 
subsystem  having  Independent  sensors,  processors,  effectors 
(displays/controls) . The  partitioning  of  the  new  integrated 
system  architecture  is  shown  in  Figure  1 , Experimental  Flight 
Control  and  Night  Vision  System  for  Combat  Helxcopter.  An 
integrated  sensor  system  generates  all  required  physical  states 
for  all  functions.  Through  the  integrated  data  acquisition/ 
rocessinq/distr ibution  system  all  states  are  acquired  and  all 
unctions  are  implemented  as  application  software.  Manual  in- 


puts/outputs are  provided  through  an  integrated  effector 


A main  contribution  towards  achieving  a reduction  in  complexity 
and  cost  is  a higher  degree  of  commonality  (standardization) 
between  and  within  all  LRU's  of  the  integrated  data  system. 
MIL-STD-1553  as  a standard  interface  and  protocol  for  data 
distribution  between  LRU's  is  the  step  towards  commonality 
between  LRU's  in  a distributed  system.  This  data  high  way  is  a 
tool  for  functional  partitioning  and  flexible  modular  inte- 
gration at  the  LRU- level. 


A second,  but  consequent  step  with  the  goal  for  higher 
commonality  is  comparable  to  the  MIL-STD-1553  approach  de- 
fining a standard  for  the  data  way  on  the  LRU  level.  A 
standardized  data  way  on  the  module  level  within  each  LRU  is 
proposed.  Figure  2,  Basic  Data  System  Configuration, 
illustrates  the  concept.  IC-boards  as  modules  in  each  LRU  re- 
presenting one  or  more  functions  as  I/O-Converters  (ADC,  SDC, 
FDC,  ...  and  vice  versa  ...  Mj^  1-Bus-Couplers , ...),  data  pro- 
cessors eind  memories  have  to  be  connected.  A parallel  bus 
has  proven  as  an  appropriate  solution  for  the  interfaces  and 


transmission  techniques  as  data  way  between  a number  of 
different  or  Identical  modules.  As  in  the  MIL-STD-1 553 , 
an  Interface  and  protocol  specification  is  provided  leaving 
space  for  the  individual  engineering  development  of  functio- 
nal modules  for  data  acquisition  and  processing  in  the  LRU 
and  for  technological  innovations.  But,  for  a certain  time 
period,  also  a developed  set  of  functional  modules  can  be 
used  in  all  different  LRU's  in  a system  in  which  the  same 
functions  are  required  (I/O,  data  processors,  memories  ...) 
with  the  expected  implications  on  cost  due  to  a higher  de- 
gree of  commonality. 

The  concept  utilizes  the  MIL-STD-1553  data  bus  as  the  data 
highway  for  communication  to  and  from  all  LRU's.  All  LRU's 
are  designed  out  of  functional  modules  arranged  along 
parallel  data  ways. 


DATA  ACQUISITION.  PROCESSING 
AND  DISTRIBUTION 


Kiquro  1 

Experimental  Flight  Control  And  Night  Vision 
System  For  Antitank  Helicopter 


DATA  HIGHWAY 


MIL-STD  1553  SENSORS/EFFECTORS 


Figure  2 

[nf'l  DURNIER I BASI C Configuration 

Integrated  Modular  Data  Acquisition, 
Processing  And  Distribution 
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THE  PARALLEL  DATA  WAY 


The  parallel  data  way  is  controlled  by  a computer  or  micro- 
processor via  the  data  way  controller.  This  is  the  bus- 
master-device.  The  remaining  part  of  the  systems,  the  modules, 
are  in  a slave  mode.  The  data  way  uses  a 16  bit  data  word. 
There  may  be  up  to  32  modules  on  each  data  way.  Figure  3 
shows  the  overall  design. 
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Data  Way  Control^ 


Addressing  of  the  modules  is  done  by  32  stich  lines  N 
running  from  the  data  way  controller  to  the  modules.  Three 
function  lines  F00-F02  are  used  to  command  and  control  the 
modules.  This  lines  are  decoded  In  the  modules. 

These  modules  are  usually  passive,  operating  In  slave  mode. 

But  there  are  provisions  for  a vectored  interrupt  system.  This 
uses  a daisy-chain  approach  through  lines  ALI , ALA  and  ALO 
leading  to  one  hardware  priority.  If  there  is  an  interrupt 
pending,  the  master  device  transmits  a "give  me  the  interrupt 
code"  command  and  the  Interrupting  module  transmits  the  module 
address  back,  which  is  used  as  an  interrupt  pointer. 

The  system  was  designed  for  a very  simple,  easy  to  understand 
operation.  This  leads  to  only  three  different  data  way 
operations: 

- WRITE  data  from  the  master  device/data  way 
controller  to  a module 

READ  data  from  a module 

READ  INTerrupt  vector. 

The  data  way  is  16  bit  wide  using  16  parallel,  bidirectional 
lines.  Transfer  is  synchronized  by  a hand-shake  protocol. 
Hand-shake  is  on  both,  leading  and  trailing  edge  of  data  and 
is  implemented  using  two  lines,  a function  strobe  line  FS  and 
a function  strobe  acknowledge  line  FSA.  The  direction  of  trans- 
fer is  marked  by  line  RW  (Read/Write) . The  manner  by  which  a 
transfer  is  established  is  illustrated  in  Figure  4.  A read 
transfer  here  is  used  for  explanation. 
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Figure  4 : Read  Transfer  from  Module  to  Controller 


Read  transfer  from  module  to  controller  - The  controller  or 
processor  generates  the  address  signal  N and  transfers  the 
instruction  (module  function  F and  direction  of  transfer  RW) 
to  the  dataway.  The  addressed  module  decodes  the  command  and 
connects  its  data  lines  to  the  dataway.  After  a certain  time, 
about  0.2  us,  required  by  the  module  to  safely  recognize  the 
command,  the  controller/processor  generates  the  function 
strobe  "FS".  This  signal  initializes  the  desired  module 
function.  If  this  is  a valid  function,  the  module  genexates 
the  function  strobe  "acknowledge  signal  FSA".  The  FSA  signal 
is  not  set  in  case  of  an  not  allowed  function  desired  from 
the  module.  The  controller/processor  accepts  the  data  trans- 
mitted by  the  module  and  resets  the  function  strobe,  signal  FS . 
This  causes  the  module  being  addressed  to  reset  the  FSA- 
signal.  Data  and  command  channels  are  maintained  for 
approximately  0.2  us  after  the  FSA  is  reset.  A short  time- 
interval  is  inserted  between  the  end  of  a read  transfer  and  the 
beginning  of  the  next  operation,  to  allow  for  a possible 
interrupt  to  be  properly  recognized. 
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The  write  transfer  is  very  similar.  All  operations  are  per- 
formed in  an  asynchronous  mode.  The  timing  is  very  simple, 
only  the  necessary  minimal  times  are  specified.  Table  1 
summarizes  the  function  of  all  incorporated  data  way  signals. 


TABLE  1 

Data  Way  Signals 


Section 

Signal  N.«iu' 

Symbol 

Line 

Character i St ic 

Signal  Direction 

Command 

Module  Address 

Ni(i='1....12) 

Dedicated  Lines 

Control  ler->Module 

Module  Function 

FOO,  F0l,F02 

Unidirect ional 
Bus  Line 

Control  ler  •■Modules 

Direction  of 
Trai\sfer 

RW 

Unidirectional 

Bus  Line 

Control  ler-Hlodules 

Reset 

RST 

Unidirect ional 
Bus  Line 

Con  troll  e r-+Mi.xiu  1 e s 

Data 

Data 

DOO-D15 

Bidi rect iona 1 

Bus  Line 

Control ler>Modules 

Function  Strobe 

FS 

Unidi rect iona 1 

Bus  Line 

Contr  o 1 1 er-g^odul  es 

Control 

Function  Strobe 
Acknow 1 edqemen  t 

FSA 

Unidirectional 
Bus  Line 

Modu  1 e s H-'cn  t r o Her 

Collective  Alarm 

Al.I 

Collective  Line 

Modules-n'ontrol  lei 

Alann 

Interrogation 

AlA 

Unidirectional 
Bus  Line 

Control  lot'+Motlvilos 

Special 

NSI.l,  NSL2 
SLl,  SL2 



Indicated  Lines 

U n i d i r ec  t i ona 1 

Bus  Line 

— 

Control  1 ei->Modu  1 e 
Cont  rol  ler->Modules 

It  should  be  understood,  that  in  an  interface  standard,  not  only 
the  data  way  and  its  protocol  has  to  be  specified.  It  also  is 
necessary  to  specify  signal  levels,  physical  dimensions, 
connectors  and  so  on.  Signal  levels  and  power  supply  voltages  are 
adapted  to  CMOS  (RCA  4000  and  similar  series);  the  physical 
dimensions  of  the  modules  fit  in  an  ARINC  1/2  ATR  box 
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The  standard  described  here  in  an  abbreviated  form  is  not 
firmly  standardizing  the  total  system  layout.  But  it  is 
sufficient  and  leads  tc  flexible,  well  structure;;! , easy  to 
service  equipment  and,  as  a result,  to  reduced  life  time 
cost.  Since  it  is  only  an  interface  standard  it  accomodates 
future  technologies  and  future  requirements  at  minimum  cost. 


SOFTWARE 

The  system  described  herein  offers  a set  of  established  rules 
for  designing  well  structured  hardware.  This  is  of  great 
influence  and  help  within  the  area  of  software. 

For  many  years  the  German  Government  has  sponsored  efforts  to 
develop  a real-time-language  for  embedded  computer-systems  in 
the  industrial  area.  This  language  is  called  PEARL  (Process 
and  Experiment  Automation  Realtime  Language)  and  includes  all 
necessary  features  for  the  programming  of  real  time  systems. 

The  level  of  the  language  is  rather  high  as  compared  for  in- 
stance with  the  DOD-1  system- language  under  definition  now. 

One  very  important  feature  of  PEARL  is  the  inclusion  of  a I 

"system-part",  which  is  used  to  define  the  hardware  environ- 
ment of  the  specific  software.  For  instance,  it  is  possible 
to  define  the  hardware  down  to  registers  in  I/O-modules.  The 
features  of  the  language  allow  for  low  cost  programming,  trans- 
parent documentation  and  low  life  time  costs  of  software.  It 
should  be  understood  that  a language  of  that  Icind  needs  an 
executive  system  as  a runtime  environment.  The  executive  is 
specific  to  the  used  hardware,  since  it  is  partly  the  compiler 
too.  If  the  hardware  is  well  and  evenly  structured,  there  ‘is 
a good  chance  to  implement  executive  and  compiler  in  a very 
general  way  without  paying  to  much  for  this  generality. 

This  was  done  on  the  basis  of  the  hardware  standard  presented 
here.  The  result  was  a PEARL-compiler  and  a very  modular 
executive  system.  The  generation  of  the  specific  executive  is 
done  at  compile  time  during  code-generation.  The  compiler  uses 
the  information  given  in  the  systems  part  of  the  program  and 
a list  of  the  language  constructs  called.  The  results  of  the 
effort  are  encouraging.  For  medium  sized  systems  using  several 
tas)(s,  clocking,  sema's  etc.  the  size  of  the  executiv  e about 
1 K 16  bit  words.  This  is  about  0.25  K overhead  compared  to  a 
tailored  solution  written  in  assembly  language. 


440 


The  overhead  produced  by  the  compiler  is  in  the  order  of  10% 
to  50%  depending  on  the  language  used.  The  10%  overhead  in- 
cludes arithmetic,  simple  branching  etc.  The  50%  overhead 
occurs  as  a worst  case  with  array  processing  in  indexed  loops. 

The  total  overhead  produced  by  the  compiler  - without  exetutive  - 
is  usually  in  the  range  of  20%.  This  seems  to  be  an  acceptable 
result,  achieved  by  using  a well  defined  and  structured  hard- 
ware as  described  above. 


i 
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ABSTRACT 

The  development  of  a demonstration  model  multiplexing 
system  for  audio  intercom  communications  has  been  sponsored 
by  the  Naval  Air  Development  Center  (NADC).  The  model  sys- 
tem codes  audio  information  using  a continuous,  variable- 
slope,  delta-squared  modulation  technique.  Audio  frequency 
response  is  limited  for  voice  recognition  and  intelligibil- 
ity, minimizing  data  rate  requirement.  Relations  between 
audio  sampling  rate,  intelligibility,  bus  loading,  and  capa- 
city for  additional  terminals  are  discussed. 

Transmission  is  in  MIL-STD-1553  formats.  A form  of 
ij  sarnie  bus  allocation  is  used  to  control  the  intermittent 
-quirements  for  data  transmission.  The  system  can  share  a 
b js  vith  other  avionic  systems  using  1553  protocols.  Bus 
av^iiability  requirements  for  a shared  system  are  discussed, 
relating  availability  to  apparent  audio  delay. 

Advantages  of  the  digital  system  are  covered,  including 
ability  to  share  communications  channels  with  other  data, 
suitability  for  scrambling  or  encryption,  and  incorporation 
or  alarms  or  warnings. 

PROBLEM  STATEMENT 

The  problem  statement  is  associated  with  the  develop- 
ment, design,  and  fabrication  of  a five-station,  general 
purpose  audio-multiplex  intercom  system  (ICS)  based  on  a 
1553  time  division  multiplexing  technique  for  the  purposes 
of  experimentation  and  laboratory  evaluation  by  NADC.  The 
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objective  of  this  program  is  to  provide  an  audio-mux  system 
for  general  purpose  use  within  Navy  airborne  platforms.  The 
system  must  be  structured  so  that  it  can  be  contracted  or 
expanded  to  accommodate  a minimum  of  two  audio  stations  to 
a maximum  of  twenty.  The  approach  to  the  audio-mux  is  to 
be  one  of  total  system  integration  and  not  as  a separate 
piecemeal  system.  The  multiplexing  of  audio  signals  must 
be  accomplished  using  transmission  over  a MIL-STD-1553 
Command/Response  System  and/or  over  the  polling  structure 
as  defined  by  MIL-G-85013(AS) . 

SYSTEM  CONFIGURATION 


The  basic  audio-mux  as  shown  in  Figure  1 consists  of  a 
number  of  stations  (from  2 to  20),  avionic  tone  simulator, 
and  a system  bus  controller.  The  system  uses  a common  bus 
to  multiplex  data  and  commands  between  stations  and  between 
the  bus  controller  and  stations.  Communications  protocol  on 
the  bus  is  per  MIL-G-85013(AS)  polling-contention  mode,  while 
data  transfers  between  elements  of  the  audio-mux  are  per- 
formed per  MIL-STD-1553A  waveform  and  timing  requirements. 
This  combination  is  equivalent  to  MIL-STD-1553B  dynamic  bus 
allocation. 

The  avionic  tone  simulator  generates  tones  associated 
with  particular  avionic  equipment.  These  tones  are  steered 
by  the  switching  matrix  to  various  stations  to  simulate 
several  warning  tone  sources.  Each  station  receives  inputs 
from  the  avionic  tone  simulator  switching  matrix,  microphone, 
and  the  intercom  system  mux  bus,  and  provides  outputs  to  the 
mux  bus,  headset,  and  recorder. 

SYSTEM  FEATURES 

The  AiResearch  general  purpose  audio-mux  system  is 
designed  for  five  stations,  expandable  to  twenty  or  more. 

The  communication  method  and  transmission  format  adopts 
the  physical  operating  and  general  message  characteristics 
associated  with  MIL-STD-1553A  (or  B).  All  message  protocol 
and  associated  control  data  and  status  words  are  trans- 
mitted over  the  same  1553  bus. 

Multiple  communications  modes  highlight  yet  another 
feature  of  the  ICS.  This  system  is  designed  to  provide  the 
following  operational  modes: 

(1)  "Party  line"  operation — one  person  talks  and  all 
others  listen. 
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"Separate"  conver sat ion--mul t iple  2-way  communi- 
cations. Bus  capacity  up  to  approximately  ten 
conversations . 


(3)  Combination  of  modes  (1)  and  (2). 

The  ability  to  mix  both  "party  line"  and  "separate" 
conversations  represents  a natural  by-product  associated 
with  the  successful  development  of  the  NADC  audio-mux 
program. 

In  addition  to  providing  for  conversations,  the  ICS 
also  handles  aural  warnings  from  various  avionic  sources. 

These  warnings  might  consist  of  those  associated  with  IFF, 
sonar,  RAWS,  altitude,  landing  gear,  and  others.  Gener- 
ally, these  warnings  have  unique  audio  characteristics  that 
allow  segregation  as  to  the  specific  warning  taking  place. 

For  example,  an  oscillator  of  1050  +50  pulses  per  second 
produces  an  IFF  warning  tone  in  contrast  to  that  of  summing 
512-Hz,  614-Hz,  and  768-Hz  oscillators  that  provide  still 
another  tone  particular  to  altitude  warnings. 

Any  warning  tone  or  combination  of  tones  may  be  switched 
to  any  station.  These  warning  tones  are  then  encoded  to  a 
specified  bit  position  of  the  first  data  word  of  the  message 
transmitted.  This  method  provides  the  presence  of  this  warn- 
ing condition  to  other  receiving  terminals  via  the  multiplex 
bus.  The  receiving  terminal  then  reads  the  corresponding  bit 
position  of  this  data  word  and  triggers  an  oscillator.  This 
produces  a warning  tone  that  can  be  audibly  mixed  with  an 
on-goinq  conversation,  permitting  both  the  warning  tone  and 
voice  communcation  to  be  heard.  The  demonstration  system 
handles  five  warnings  with  capacity  designed  for  sixteen, 
requiring  no  change  to  message  or  data  word  formats.  Since 
multiple  warnings  may  be  introduced  to  a terminal  at  one  time, 
indicators  are  provided  at  each  terminal  for  verification  of 
each  warning  condition. 

AUDIO  PROCESSING 

In  past  reviews,  multiplexing  voice  over  1553  type 
data  bus  has  appeared  difficult  and  impractical.  This 
stemmed  mainly  from  the  continuous  nature  of  the  analog 
voice  signal  as  compared  to  the  quantized  1553  digital 
system's  20-microsecond  words.  Systems  have  beer  con- 
sidered where  the  transmission  of  a single  voice  signal, 
in  a digital  form,  would  load  the  system  and  not  allow 
time  for  the  transmission  of  any  other  signals. 


A different  system  concept  from  those  previously 
considered/  along  with  modern  integrated  circuits,  have 
made  audio-multiplexing  practical  for  future  systems. 

A first  consideration  in  digital  audio-multiplexing  is 
how  much  data,  bits  per  second,  is  required  to  be  trans- 
mitted. The  AiRes jarch-developed  entertainment  multiplexing 
system  of  a few  years  ago  used  300,000  bits  per  second.  This 
was,  in  fact,  a hi-fi  system.  Some  of  the  new  companding 
(nonlinear  PCM)  integrated  circuits  for  telephones  use  8 kHz 
samples  of  8 bits,  64,000  bits  per  second.  These  systems 
should  produce  extremely  high  voice  quality.  Recently  pro- 
duced integrated  circuits  for  voice  use  16,000  bps  and  greater 
bit  rates.  These  units  use  versions  of  delta  modulation  (one 
bit  A/D)  called  continuous,  variable-slope  delta  modulator 
and  accommodate  a wide  dynamic  range  of  signals.  Aural  warn- 
ing systems  have  been  built  (AiResearch  for  NASA)  using  delta 
modulation  at  an  even  lower  data  rate  (10,000  bits/sec), 
but  voice  quality  was  just  adequate  for  the  intended  word 
recognition  requirement,  but  not  for  voice  recognition. 

The  1553  data  bus,  of  course,  has  a capacity  of 
1,000,000  bits  per  second.  The  NADC  specification  called 
for  a system  expandable  to  20  stations.  If  all  20  are 
allowed  to  talk  at  once  (not  necessarily  a requirement), 
then,  not  considering  bus  operating  overhead,  the  maximum 
sample  rate  would  be  59,000  bits  per  second.  Synchroniza- 
tion and  parity  bits  associated  with  1553  transmission  use 
20  percent  of  the  bus  capacity,  lowering  the  maximum  possi- 
ble rate  to  40,000  bits  per  second.  Other  overhead  asso- 
ciated with  the  bus  operation  reduces  the  bit  rate  even 
further.  The  audio-multiplexer  uses  a 25  kHz  sample  rate 
to  meet  the  20-station  requirement  with  reasonable  quality. 
Voice  recognition  at  this  rate  is  very  good.  Future  systems 
may  use  lower  frequencies  (like  16  kHz)  with  newer  integrated 
circuits. 

At  25  kHz  sample  rate,  a bit  is  generated  every  40 
microseconds.  Since  this  is  two  1553  word  times,  it  is 
impractical  to  handle  the  bits  individually  over  the  bus. 
However,  if  bits  are  stored  in  the  transmitting  station 
until  an  appropriate  quantity  is  available  and  then  trans- 
mitted in  groups,  a convenient  system  may  be  devised. 
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Consider  the  following  analogy:  there  are  two  large 
buckets,  as  shown  in  Figure  2.  One  bucket  has  water  running 
into  it  at  a fixed  rate,  and  the  second  bucket,  with  an 
outflow  spigot,  has  water  running  out  at  the  same  fixed 
rate  as  the  water  to  the  input  bucket.  You  stand  by  the 
buckets  with  a dipper.  When  the  water  level  in  the  first 
bucket  reaches  a certain  level,  you  move  a dipper  of  water 
from  the  first  bucket  to  the  second.  You  repeat  this  pro- 
cess at  such  a rate  that  the  first  bucket  never  overflows 
and  that  there  is  always  enough  water  in  that  bucket  for 
your  dipper  when  you  dip.  If  the  input  to  the  first  bucket 
and  the  output  from  the  second  are  exactly  equal,  then  the 
output  from  the  second  will  be  continuous  and  uninterrupted. 
Note  that  over  a long  period  of  time  the  rate  of  water 
moved  by  the  dipper  is  (and  must  be)  the  same  as  the  input/ 
output  on  the  bus.  Another  operational  analogy  to  be  gar- 
nered from  this  model:  the  output  of  a particular  segment 
of  water  does  not  occur  directly  after  its  input;  there 
is  a built-in  delay. 

ICS  COMMUNICATION 

The  AiResearch  audio-multiplex  system  operates  much  as 
the  model  described.  The  transmitter  converts  voice  to 
bits  and  stores  512  before  transmission  can  start.  Approxi- 
mately every  10.24  milliseconds,  256  voice  bits  (16  data 
words)  are  transmitted.  In  the  receiving  station(s),  512 
bits  are  received  (two  transmissions)  and  stored  before  the 
analog  output  is  started.  The  delay  through  the  system  from 
voice  in  to  voice  out  is  approximately  40  to  50  milliseconds, 
below  the  threshold  of  perceptibility  to  the  user. 

Upon  power  turn-on,  the  bus  controller  offers  the  mux 
bus  to  the  first  audio-mux  station  and  sets  an  internal 
timer  within  the  bus  controller.  The  bus  controller  then 
tests  the  bus  status  to  determine  if  the  bus  is  busy.  When 
the  bus  enters  the  idle  state,  the  bus  controller  can  offer 
the  bus  to  tl:e  next  audio-mux  station.  The  bus  controller 
continues  this  activity  until  all  stations  have  been  offered 
the  bus.  The  controller  then  waits  until  the  sample  time 
interval  (10  milliseconds)  has  been  reached.  The  bus  con- 
troller then  resets  the  counter  and  offers  the  bus  again  to 
audio-mux  system  stations.  When  the  bus  is  offered  to  a 
station  it  will  not  respond  if  it  has  no  message  to  transmit, 
and  the  bus  controller  will  reacquire  the  bus.  If  the  sta- 
tion has  a message,  it  transmits  a command  (receive)  to  the 
first  station  as  defined  by  the  address  switches.  This 
latter  station  (receiving)  will  transmit  a status  word  back 
to  the  first  (transmitting)  station.  A bit  in  the  status 


Figure  2.  Bucuet  by  Bucket  Analogy 


word  will  indicate  if  the  receiving  station  is  busy.  Il 
the  transmitting  station  is  communicating  to  other  stations, 
it  will,  after  receiving  the  first  receiving  station's 
status  word,  transmit  a command  (receive)  to  the  next  sta- 
tion and  receive  a status.  This  continues  until  all  sta- 
tions to  receive  have  been  notified  and  have  responded; 
the  transmitting  station  then  transmits  17  data  words 
that  will  be  received  by  all  receiving  stations  at  the 
same  time. 

All  stations  receive  a bus  offer  each  10.24  millisecond 
frame.  Communications  can  occur  simultaneously  between  two 
stations.  Audio-mux  communication  protocol  and  message 
word  formats  are  presented  in  Figures  3 and  4,  respectively. 

STATION  DESIGN 

One  of  the  demonstration  stations  is  shown  is  Figure  5. 
A station  consists  of  input  and  output  amplifiers,  variable- 
slope,  delta-squared  decoder  and  coder,  input  and  output 
memories,  a bus  transmitter  and  bus  receiver,  switch  address 
logic,  warning  circuits,  and  microprogram  controller.  A 
block  diagram  of  the  station  is  presented  in  Figure  6. 

The  input  amplifier  scales  and  filters  the  incoming 
audio  signals.  The  delta  squared  coder  converts  the  analog 
signal  into  a series  of  digital  pulses.  These  pulses  are 
stored  temporarily  in  the  transmitter  memory.  When  suffi- 
cient data  is  stored,  it  will,  under  microprogram  control, 
be  output  to  the  bus  transmitter. 


The  bus  transmitter  outputs  the  data  to  the  bus,  again 
under  microprogram  control,  when  the  appropriate  control 
word  has  been  received  from  the  bus  controller. 

The  bus  receiver  receives  data  from  the  bus  and  out- 
puts the  data  to  address  comparison  logic,  the  receiver 
memory,  and  warning  circuits.  Under  microprogram  control, 
the  receiver  determines  the  type  of  data  from  the  address 
comparison  units,  and  bus  receiver  control  bits  (command 
sync,  data  sync,  etc.);  then,  when  appropriate,  it  directs 
the  data  to  the  receiver  memory. 

In  the  receiver  memory  the  data  are  stored  temporarily 
until  required  by  the  decoder.  The  decoder  converts  the 
digital  data  back  into  an  analog  signal,  which  is  then  out- 
put to  the  headset. 
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(5)  Turn  on  appropriate  warning  lights. 

The  switch  address  logic  generates  the  appropriate 
station  address  from  the  toggle  switch  inputs.  This  infor- 
mation is  transmitted  under  microprogram  control. 


Two  principal  areas  associated  with  audio-mux  design 
required  particular  attention  during  design  and  development 
phases  of  the  system.  The  first  was  optimizing  encoding/ 
decoding  for  the  highest  degree  of  audio  fidelity  versus  the 
number  of  bits  per  data  word  required  to  produce  the  audio 
tone.  The  second  was  the  packing  and  unpacking  of  audio 
data  which  required  a tradeoff  analysis  between  message  size 
and  fidelity  versus  the  number  of  stations  in  the  system.  ^ 
significant  factor  in  this  decision  is  the  optimization  of 
memory  sizes  within  the  station  compared  with  transmission 
time  and  bus  loading  associated  with  the  number  of  stations. 


FUTURE  TRENDS 


Many  applications  exist  for  future  versions 
basic  audio-mux  as  described  in  this  paper.  The 
assume  a wide  variety  of  configurations  for  both 
and  ground  based  systems.  A possible  configurat 
ICS  for  airborne  use  is  presented  in  Figure  7. 


of  the 
ICS  could 
airborne 
ion  of  the 


In  addition  to  the  many  different  1553  system  config- 
urations that  the  ICS  might  assume,  it  could  be  thought  of 
as  a prime  candidate  for  the  new  technology  of  fiber-optic 
multiplexing.  Due  to  the  bus  transmission  rates  attainable 
with  a fiberoptic  bus  (around  20  MHz)  and  the  limitations 
apparent  in  the  number  of  stubs,  audio-multiplexing  repre- 
sents one  of  many  systems  that  could  easily  be  integrated 
using  this  multiplexing  technique. 
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Figure  7.  A Possible  Future  Configuration 


SUMMARY  AND  CONCLUSION 

The  challenge  of  developing  a practical  audio- 
multiplexing system  using  MIL-STD-1553  formats  is  addressed 
by  AiResearch  in  the  design,  development,  fabrication,  and 
test  of  the  ICS  demonstration  system  for  the  Naval  Air 
Development  Center.  AiResearch  defined  a system  configura- 
tion, developed  the  requirements,  and  resolved  audio  pro- 
cessing and  communication  tradeoffs.  AiResearch  also 
produced  operational  development  hardware  that  provides  a 
baseline  for  future  ICS  configurations. 

The  AiResearch  audio-multiplexing  system  represents 
the  first  step  to  development  of  operational  audio  multi- 
plexing systems.  These  would  take  into  account  the 
advantages  in  reducing  station  size,  weight,  and  power 
requirements  by  using  LSI  and  hybrid  devices. 
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1. 


I nt  roducti on 

Modern  generation  aircraft  are  nowadays 
widely  utilizing  the  Party-Line-Principle 
seriel  Data  Bus  for  Data  Transmission  be- 
tween the  verious  "Black  Boxes". 

In  the  military  domain  MI L-STD- 155 3A  is 
almost  exclusively  applied  while  in  the 
civil  aircraft  industry  a similar  system, 
which  corresponds  to  ARINC  429,  is  used. 

Besides  the  transmission  of  Data  between 
digitalized  system  units  a more  or  less 
greater  number  of  discrete  on/of f-s i gnal s 
is  necessary  between  the  single  units  or 
components  of  the  aircraft. 

Of  course,  these  signals  could  be  transmitted 
via  a Data  Bus  according  to  MI L-STD- 1553. 

For  example  a corresponding  Dat a- Bus -Te rmi na 1 
would  be  able  to  process  16  discrete  signals 
§ in  one  transmission.  However  as  in  the  past, 

these  signals  must  then  be  transmitted  to  the 
corresponding  s i gnal -source  or  sink  via  signal 
lines  (refer  to  figure  1). 

The  following  reasons  are  in  contrast  to  this 
solution: 

a.  a large  number  of  single  wires  must  be 
attached  to  the  Data  Bus.  System  modi- 
fications would  therefore  require  a wiring 
change . 

b.  A Data-Bus-Termi nal  is  rather  complex. 

The  extreme  demands  to  discrete  signals 
with  regards  to  reliability  can  only  be 
met  by  employing  pedrundant  systems. 
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The  above  mentioned  reasons  should  therefore 
justify  a special,  if  possible  very  simple 
Bus  system  for  transmitting  these  discrete 
signals. 

This  does  however  not  preclude  the  fact,  that 
signals,  which  are  anyway  necessary  on  the 
Oata-Bus  or  which  come  from  there,  will  ho 
transmitted  there.  The  distribution  of  the 
signals  from  the  Da t a- Bus -Te rmi na 1 can  now  be 
accomplished  via  the  Discrete-Bus.  Also,  the 
majority  of  the  signal  source  can  now  be  di- 
rectly transmitted  to  the  sink  via  the  Discrete- 
Bus  (refer  to  figure  2). 

Discrete-Bus  system  demands 

Following  are  the  most  important  requirements  : 
High  Reliability 

The  reliability  can  be  measured  against  the 
conventional,  uncomplicated  single  wire  con- 
nections. In  order  to  obtain  such  high  relia- 
bility values  redundancy  must  be  easily  possible 

Extreme  small  amount  of  Hardware 
Components  generating  or  receiving  discret 
signals  (switches,  relais  aso)  are  usually  small 
in  size.  A requirement  for  bigger  Hardware- 
similar  to  the  one  used  in  the  Da ta-Bus -Te rmi na 1 
would  be  inadequad.  The  hardware  must  there- 
fore be  so  small  in  size  that  it  can  be  inte- 
grated into  the  components  without  substantially 
changing  the  size  or  shape  of  the  components 
which  are  commonly  in  use  today. 
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Hence,  the  necessity  to  employ  only  one  IC 
with  the  minimum  amount  of  peripheral  components 
is  only  too  obvious. 

2.3  decentralized  Structure 

A central i zed  system  control  or  system  orga- 
nization will  only  create  reliability  problems. 
Additionally,  it  should  be  possible  to  operate 
the  system  efficiently  either  with  few  or  many 
members  connected  to  it.  Of  course,  the  decen- 
tralized control  of  the  Data  flow  does  not 
exclude  the  possibility  to  channel  the  Data  flow 
via  a central  processing  unit  due  to  systeni- 
requi remen  ts . 

2.4  Unproblematic  transmission  line 

In  order  to  simplify  the  installation  it  should 
be  no  problem  to  use  stub  lines.  Additionally 
the  safety  margin  against  interruptions  can 
be  increased  by  closing  the  transmission  line 
to  a loop. 

2.5  Transmission  speed 

In  order  to  increase  the  EMC- s up  res s i on  and 
to  simplify  the  handling  characteristics  the 
transmission  speed  should  be  as  low  as  possible 
but  sufficiently  high  to  cover  the  full  appli- 
cation range. 
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2.6  Type  of  Transmission 
Storing  instructions  in  the  receiving  portion 
of  the  system  increases  - EM  - susceptibility. 

For  this  reason,  the  instructions  should  be 
transmitted  periodically.  Also,  the  "ON/OFF" 
signals  must  be  actively  transmitted  in  order 
to  eliminate  any  malfunction  during  fault  - 
conditions  or  during  absence  of  instructions 
when  the  system  is  only  partially  operated. 

2.7  Easy  and  reliable  system  testing 
It  should  be  possible  to  monitor  the  system 
functions  during  operation  from  a central  unit 
as  well  as  detecting  and  pin-point  faults  to 
the  single  member. 

2.8  Logical  Functions 
No  additional  hardware  should  be  necessary 
to  obtain  the  logical  functions  which  are 

realized  in  today's  systems  by  connecting  f! 

contacts  in  series  or  parallel. 

3.  Basic  thoughts  for  system  realization 

The  full  integration  into  the  controlling 
or  controlled  system  components  is  necessary 
so  that  the  transmission-system  does  not  appear 
as  separate  equipment.  This  can  only  be  achieved 
if  the  complex  functions  of  the  system  are  inte- 
grated on  a special  MOS-chip  without  the  need 
for  a bigger  amount  of  additional  discrete 
components . 
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For  this  reason  the  quartz,  which  are  nor- 
mally necessary  for  the  clock,  has  to  be 
substituted  by  a simple  RC-osz i 1 1 ator  with 
a lower  accuracy.  That's  possible  using  a 
special  synchronisation-methode.  So  only  an 
external  capacitor  is  necessary  for  coupling 
the  member  from  the  Bus  in  case  of  failure. 

An  external  resistor  is  used,  thus,  due  to  the 
extremely  simple  construction  it  is  oossible 
to  trible  the  system  without  problems  for  com- 
ponent size  and  cost.  Data  transmission  con- 
trol can  be  completely  decentralized  because 
of  the  selected  type  of  the  transmission 
channel  (wired-or)  and  by  simply  counting, 
starting  with  a synchronization  pulse  . 

Thus,  besides  a gracefull  degradation  a system 
with  even  a few  members  can  be  efficiently 
employed. 

The  "wired  or"  structure  of  the  data  channel 
allowes  the  or-function  without  additional 
measures,  while  the  AND-function  can  be  easily 
accomplished  by  the  addition  of  an  input  at 
the  individual  member.  Together  with  the  de- 
sign of  latches  at  the  signal  output  enables  the 
system  to  carry  out  all  functions  which  have 
previously  been  accomplished  by  latch-relays. 

In  order  to  ensure  suffi  ci  ent  noise  imunity  of 
the  rather  simple  transmission  line  the  lowest 
possible  transmission  speed  and  multiple  data 
transmission  technique  was  choosen  instead  of 
special  data  securing  measures. 


6 


Only  the  consecutively  third  identical  command 
triggers  the  execution  of  the  function.  In 
addition  systems  which  are  multiplied  are  wor- 
king completely  asynchronous.  Fault  pulses  will 
therefore  rarely  influence  the  same  signal  on 
all  channels,  so  an  additional  safety  margin 
is  guaranteed. 

The  system  characteristics  are  rounded  off  by  the 
possibility  to  transmit  analog  values  of 
medium  accuracy.  This  can  be  of  advantage  for 
a system  which  is  controlled  by  a di  screte-llus 
if  measuring  data  for  monitoring  purposes  are 
gathered  at  places  on  which  a discrete-bus 
data  pick-off  is  anyway  installed;  for  instance 
as  with  the  electric  power  supply  system 
(RPC,  remote  power  control).  It  is,  however, not 
intended  to  explain  this  operating  mode  in  de- 
tail. 

The  example  of  a member  for  transmitting  two 
command  signals  (ON  and  OFF)  as  described  herein 
can  naturally  be  expanded  to  more  channels  per 
member. 

4.  Functional  description 

The  first  system  lay-out  incorporates  256  mem- 
bers and  the  frame-time  is  set  to  100  msec.  Con- 
sidering three  consecutive  identical  command 
signal  transmi ss i ons  the  total  processing  time 
is  300  msec.  In  most  cases  this  should  be 
sufficient,  otherwise  the  alarm  signal  trans- 
mission, as  described  in  a later  paragraph,  should 
be  used. 
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Since  the  data  is  repeated  at  periodic 
intervals  it  is  only  too  logical  to  adress  via 
sequenc i ng . 

Using  the  direct  adress  method  would  only 
increase  the  amount  of  information  without 
resulting  in  substantial  advantages. 

Following  is  a detailed  description  of  the 
operation  : 

4.1  Transmission  channel 

A two-conductor  shielded  cable  is  used  for  the 
data-bus  transmission  line.  One  wire  represents 
the  bus-line  and  the  second  wire  is  used  as  a 
powQ'  supply  line  for  members  which  cannot  draw 
power  from  other  sources  (for  instance  a simple 
switch  acting  as  a command  originator).  But 
one  has  to  be  aware  that  a breakdown  of  this 
power  supply  will  anable  all  members  connected 
to  it. 

The  bus-configuration  is  like  a wired  or. 

(refer  to  figure  4).  The  two  pull-up  resistors 
R are  terminating  the  line  at  the  beginning  and 
the  end  . In  conjunction  with  the  decoupling 
resistors  as  described  in  paragraph  4.6  the  line 
capacity  constitutes  a low-pass.  Due  to  the 
resulting  big  rise  and  fall  times  the  line  must 
not  be  terminated  by  characteristic  impedance. 

It  is  permissible  to  use  stub  lines  and  the  bus- 
line may  be  formed  to  a closed  loop.  The  bus-line 
length  can  be  up  to  200  meters. 
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Note  : 

Of  course  it  would  be  desirable  to  operate  the 
bus-line  symmetrically  and  inductively 
coupled.  But  at  this  time  this  does  not  seem 
to  be  feasable  because  of  the  resulting  in- 
crease in  number  and  size  of  the  system  compo- 
nents. However  it  can  be  advantagous  to 
optically  decouple  the  output  or  input  signals 
of  a member  from  the  operated  component.  This 
can  be  relatively  easy  accomplished  since  the 
most  simple  event  is  one  input  and  one  out- 
put signal  only. 

4.2  Synchronization  and  adressing 

Figure  3 shows  the  typical  frame  build-up. 

It  starts  with  the  frame-synch  pulse.  The 
pulse  can  be  easily  detected  from  the  rest  of 
the  signals  by  its  characteristic  width.  The 
end  of  the  frame-synch  pulse  is  a reference 
point  for  all  members.  Each  member  starts  to 
count  the  time  slots  from  1 to  N starting  at 
this  point.  At  the  same  time  the  time  slots 
1 to  N represent  the  source  address. 

Each  time  slot  is  terminated  by  the  auxiliary- 
synchronizing pulse,  the  slot-synch.  The 
end  of  this  pulse  is  at  the  same  time  the 
beginning  of  the  next  time-slot. 

A time-slot  is  divided  into  4 bits  (a,b,c,d). 
Bit  A is  always  hight  because  the  end  of  the 
frame-synch  pulse  or  the  slot-synch  pulse  is 
the  reference  point. 
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Bit  B is  high  when  an  "OFF"  command  is  trans- 
mitted (figure  3,  address  2),  Bit  C is  high 
when  an  "ON"  signal  is  transmitted  (figure  3, 
address  1).  It  is  of  course  possible  that  bit 
A and  B is  high  (figure  3,  address  n-1). 

For  clarification  refer  to  paragraph  4.8. 

The  synchronization  pulses  are  generated  simul- 
taneously by  all  members.  Because  of  the  wired- 
or  structure  of  the  channel  the  slowest  member 
always  determines  the  end  of  the  synchronization 
pulses.  Therefore,  the  slowest  member  also  con- 
trols the  system  timing. 

Without  the  slot-synch  pulse  it  would  be 
necessary  that  all  members  synchronously  sweep 
all  256  time-slots  with  sufficient  accuracy. 

But  with  the  slot  synch  that's  only  one  time 
slot.  Therefore  it  is  possible  to  employ  a 
relatively  inaccurate  RC-osci 1 lator . 
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At  the  end  of  the  frame-time  all  members  simul- 
taneously  generate  another  frame-sync  pulse  and  l 

I ■ 

the  cycle  repeats  again  (for  exceptions  see 

I 

paragraphs  4.8  and  4.9).  [ 
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4.3  Receiver  address 

The  consecutive  numbering  of  the  time  slots 
corresponds  with  source  address  as  already 
mentioned  in  paragraph  4.2  . Hence  the  re- 
ceiving member  receives  the  information  be- 
cause it  is  programmed  to  the  same  time  slot. 

Each  IC  houses  a transmitter  and  a receiver. 

Therefore,  in  order  to  program  the  transmitter 
address  8 Pins  are  required  and  for  the  recei- 
ver address  another  8 Pins  are  also  required. 

Taking  into  consideration  that  in  th.?  majority 
of  the  applications  the  execution  of  commands 
must  be  supervised,  i.e.  the  received  command 
has  to  trigger  a feed-back  signal.  So  a fixed 
assignment  between  command-address  and  feed- 
back-address is  usefull.  According  to  figure 
5 this  assignment  is  such  that  the  command - 
address  and  the  feed- back-address  are  located 
adjacent  to  each  other.  Therefore,  only  8 Pins 
are  required  for  programming,  while  a 9th  Pin 
determines  the  function  "receive  and  transmit 
feed-back  signal"  or  "transmit  and  receive 
feed-back  signal".  In  the  case  that  no  feed- 
back signal  is  required  the  corresponding 
feed-back  address  will  not  be  used. 

Fail-Safe  behavior 

During  the  partial  operation  of  the  system  o" 

’I  * 

during  fault  conditions  the  transmitting  func- 

tion  of  a member  can  be  impaired.  j 
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The 

the 

following  can  be  a failsafe 

receiver  : 

position  of 

a . 

no  command-si  gnal-»“0FF“ 

b. 

no  command-s  i gna  1-»"0N " 

c . 

no  command-si  gnal->''mai  ntai  n 

valid  condition" 

the  last 

All  three  modes  mentioned  can  bo  programmed 
into  the  I C . 

5 Decoupling  of  the  transmitter  stage 

According  to  figure  6 the  decoupling  resis- 
tor Re  is  used  to  avoid  a break  down  of  the 
remaining  system  in  case  of  a shorted  trans- 
mitter stage.  Additionally,  this  makes  it 
possible  to  localise  the  disabled  member. 
Therefore,  in  case  of  a no  malfunction  con- 
dition a signal  voltage  is  present  on  the 
Data  Bus  per  figure  7a.  One  shorted  output 

/ 

transistor  effects  the  signal  per  figure  7b, y' 
two  shorted  output  transistors  ef feet  ,f i gure 
7c  etc. 

Thus,  the  receiver  must  be  able  to  e.xactly 
evaluate  the  signal  despite  a change  in  ampli- 
tude and  BIAS-level.  This  is  accomplished  by 
employing  the  technique" per  figure  8. 

The  peak-value  of  the  signal  voltage  is  stored 
in  Cl.  Divider  R1/R2  produces  a voltage  which 
. 'is  equivalent  to  75  t of  used  as  reference 
for  the  receiver-comparator  COMP  1. 
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The  switching-level  is  therefore  always  in  the 
middle  between  the  upper  and  the  lower  signal 
level.  This  assures  the  proper  functioning 
of  the  system  up  to  three  shorted  transmitter 
stages.  However  due  to  the  lower  signal  level 
a higher  fault  EM-sensi ti vi ty  must  be  taken 
into  consideration. 

4.6  Logical  Functions 

4.6.1  OR-Functi on 

If  members  A and  B are  programmed  to  the  same 
address  per  figure  9 the  result  will  be  an 
OR-signal  due  to  the  wi red-or-structure  of  the 
Bus.  This  signal  is  then  received  by  member  C. 

It  is  of  course  possible  to  program  any  amount 
of  members  to  the  same  address. 

4.6.2  AND-Function 

Each  member  has  its  own  additional  AND-gate. 

As  per  figure  10  member  A transmits  its  infor- 
mation to  member  B.  Within  the  integrated  AND- 
gate  this  signal  is  then  tied  together  with 
the  input  signal  E2.  The  resulting  AND-signal 
1n  turn  is  transmitted  to  member  C via  the 
adjacent  address. 
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Of  course,  any  number  of  member  can  be  tied 
into  AND-f uncti ons . 

It  must  however  taken  into  consideration  that 
the  E2  is  not  available  on  the  data-bus  for 
possible  further  use  (for  clarification  refer 
to  paragraph  7). 

4.7  Special  function  ON  and  OFF 

As  described  in  paragraph  4.2  the  bit  combination 
band  c can  be  both  high.  A specific  usage  for 
this  mode  has  not  yet  been  assigned.  It  could 
be  thinkable  to  use  this  combination  to  initiate 
test  functions  within  the  receiver.  For  example 
the  signal  E2  could  be  connected  directly  to 
the  bus  for  test  purposes  in  order  to  localize 
a possible  fault  within  complex  AND-f uncti ons . 

4.8  Alarm 

If  an  shorter  reaction  time  is  required  between 
several  members,  then  the  corresponding  trans- 
mitter can  arrange  a priority  signal  transmission 
by  prematurely  triggering  the  frame-synch  pulse 
for  three  consecutive  times  incase  of  a 
signal  change  at  the  input.  Of  course  all  mem- 
bers which  are  entitled  to  execute  an  alarm- 
transmission  will  be  programmed  to  the  beginning 
of  the  time  sequence. 
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4.9  Time  Sequencing 

If  the  system  uses  a cons i derabl e smaller  number 
of  the  scheduled  256  members  then  one  member- 
preferably  the  supervisor-can  interrupt  the 
time  sequencing  at  any  one  point  by  generating 
a frame-synch  pulse  and  start  the  sequence  again. 
This  will  shorten  the  reaction  time  of  the 
system. 

This  function  must  not  be  executed  simultaneously 
by  all  members  because  in  case  of  failure  the 
system  will  continue  to  operate,  however  at  a 
somewhat  slower  speed. 

5.  System  monitoring 

A special  system  member-the  supervisor-  will 
fulfil  this  task.  Like  any  other  member  it  is 
connected  to  the  data  bus  (refer  to  figure  11). 

It  has  monitoring  functions  exclusively.  It 
monitors  the  presence  of  command  signals,  the 
concurrence  between  command  signal  and  feed- 
back signal  and  the  concurrence  of  the  single 
channels  in  redundant  systems.  In  case  of  a 
fault  it  shows  the  address  of  the  involved 
member(s)  and  channel  .theref ore  it  is  possible 
to  automatically  localize  faults  even  to  the 
single  member. 

Fault  detection  and  fault  reporting  is  a central 
function.  In  case  of  failure  of  the  supervisor 
the  overall  functioning  of  the  system  is  not 
impai red. 
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6.  Functional  test  of  the  System 

The  initially  inactive  supervisor  can  be 
supplemented  in  order  to  test  the  functioning 
of  the  system  (for  instance  preflight  check). 
According  to  a special  test  program  stimuli 
signals  are  generated  and  the  system  reaction 
tested  as  previously  described.  These  stimuli 
signals  can  superimpose  the  original  signals, 

A high  or  a low  signal  can  be  applied  to  the 
bus,  with  low  impedance,  so  overriding  a 
members  signal. The  inflight  testing  of  the 
transmission  system  can  be  achieved  by  perio- 
dical injecting  stimuli  signals  and  cross- 
examination  the  systems  response. 

7.  Maintainability 

The  described  supervisor  will  allow  very  easy 
maintaining  the  system  because  it  is  pin  poin- 
ting a fault  down  to  the  single  member. 

But  if  there  is  no  supervisor  for  instance  if 
a system  is  checked  out  in  steps  starting  with 
only  some  members  a very  simple  little  test-book 
could  be  usefull.  This  littel  test-book  woulc 
be  connected  to  the  bus  using  test-socket  at 
convience  places.  With  a digiswitch  a source- 
address  can  be  selected  and  the  signal  indicated. 
The  same  way  a source  address  can  be  selected  and 
a command  impressed  to  the  bus.  So  it's  not  only 
possible  to  check  the  discrete  bus  system  but 
check  also  the  controlling  or  controlled  system 
componente . 
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It  is  obvious  that  in  the  same  way  a fully  auto- 
matic text  system  could  do  a complete  system 
check . 

8.  Redundant  System 

I fail  operational  system  is  a must  a bus  system 
can  be  easily  multiplied.  Because  the  system  is 
a extremely  small  and  cheep  there  are  no  cost  or 
space  limitations.  The  systems  will  run  fully 
independent  and  not  synchronized.  Due  to  this  a 
noise  pulse  will  hardly  influence  the  same  address 
so  improving  the  EMC  characteristic. 

9.  Transmission  of  analog  values 

For  this  function  a slightly  modified  member 
is  used.  One  pair  of  addresses  is  carrying 
8 data-bit.  This  resolution  normally  is  sufficient 
for  supervisory  purposes.  A functional  description 
of  this  member  will  be  given  later. 

10.  Figure  12  is  showing  the  block-diagram  of  a 
receiving  and  transmitting  member. 

Having  in  mind  the  earlier  paragraphs  it  should 
be  self  explaining. 

11.  Conclutions 

In  our  opinion  the  main  advantages  of  the  proposed 
systems  are  : 

a)  gracefull  degradation  due  to  the  decentral 
controlling  method 

b)  extremely  simple  hardware,  therefore  light  weight, 
cheep  and  reliable 
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c)  multiplying  is  possible  without  any  problems 

d)  sensefull  applicabel  also  with  few  members 

e)  easy  to  test  and  maintain 

f)  felxibel  in  case  of  system  changes  and 
extanti ons . 

Due  to  this  qualities  we  think  it's  worth  to 
think  about  it  as  an  alterate  for  wirering  dis- 
crete signals  in  the  conventional  method  or 
using  the  databus-system. 
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Apend i x 

State  of  the  program,  January  1978  : 

Using  standard  MSI  components  about  16 
digital  members  and  some  analog  members,  have 
been  built,  (see  fig.  11.  Then  using  little 
hard-wired  test  boxes  (see  fig.  2)  the  system 
was  checked  out  in  all  modes.  Limited  IMC 
tests  will  start  very  soon. 

Some  of  the  functional  models  were  delivered 
to  VFW  to  be  tested  in  a remote  power  control 
system  using  the  electrical  power  RIG  of  the 
VFW  614. 

Some  other  functional  models  are  being  tested 
in  VDO  for  use  in  bigger  land  vehicles. 


In  addition  a databus  terminal  MIL-STD  1553  A 
(modified)  will  be  extended  to  commect  with  the 
discrete  bus  system. 
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DEVELOPMENT  OF  THE  MIL-STD-1553  MULTIPLEX  APPLICATIONS  HANDBOOK 

C.  Ray  Turner 
The  Boeing  Company 
Seattle,  Washington  98124 


ABSTRACT 

This  paper  is  intended  to  give  the  reader  some  concepts  and 
expectations  of  the  content  of  the  Air  Force  Systems  Command  sponsored 
Multiplex  Applications  Handbook, 

BACKGROUND 

The  draft  MIL-STD-1553B  (16  June  1978)  states  "Even  with  the  use  of 
this  standard,  subtle  differences  will  still  exist  between  multiplex 
buses  used  on  different  aircraft  due  to  the  options  allowed  in  the 
standard" . (Underlining  by  the  author  of  this  paper.)  Also  the  draft 
states,  "These  designer  selected  options  must  exist,  so  as  to  allow 
the  necessary  flexibility  to  assemble  a custom  multiplex  system  from 
the  functionally  standard  parts  and  to  program  the  standard  electronic 
functions  in  order  to  provide  a control  mechanism,  traffic  patterns, 
redundancy,  and  a viable  degradation  concept". 

The  question  is:  how  to  achieve  standardization  without  overcontrol, 
excessive  cost,  or  stifling  of  technology.  MIL-STD-1553  was  written 
to  help  solve  a problem:  proliferation  of  digital  signal  interfaces 
of  various  aircraft  avionics  systems.  While  the  standard  does  reflect 
very  significant  industry  input  and  agreement,  the  actual  statements 
are  necessarily  brief,  and  independent  of  any  particular  multiplex 
system  architecture,  hardware,  or  software.  And  it  is  permissive. 
Standard  digital  signal  interfaces  are  being  used,  and  the  integration 
approach  of  1553  is  well  accepted,  but  minor  application  design 
deviations  which  can  cause  interoperability  problems  are  occuring. 

In  view  of  the  fact  that:  (a)  the  rationale  for  the  standard  is  not 
in  the  standard;  (b)  past  experience  and  "lessons  learned"  in 
implementing  MIL-STD-1553  is  not  generally  available;  (c)standards 
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with  handbooks  have  been  an  effective  combination  in  other 
technologies;  the  Air  Force  Systems  Command  is  sponsoring  a program  to 
prepare  a handbook  which  will  present  the  design  considerations  and 
trades  which  need  to  be  accomplished  to  implement  a MIL-STD-1553 
multiplex  system  for  aircraft.*** 

WHY  THE  HANDBOOK  IS  SEEDED 

Several  anticipations  exist  of  what  the  handbook  will  do  for  industry 
and  for  the  Air  Force,  as  sponsor. 

Industry  View;  The  aerospace  industry  that  serves  the  DOD  is 
organizationally  quite  dynamic  and  flexible.  Reassigned  managers,  who 
have  appropriate  digital  systems  experience  but  no  background  in 
multiplexing  for  aircraft  will  use  the  handbook.  Engineers  also  get 
reassigned.  And  college  graduates,  too,  will  need  help.  The  handbook 
will  help  get  them  up  to  date  and  productive.  In  each  case,  tutorial 
sections  are  needed.  Existing  designers  of  1553  systems  will  want  to 
see  information  on  systems  designed  by  others;  how  was  the  data 
processing  partitioned,  what  sensors  were  used,  etc.  Therefore,  the 
handbook  will  be  a technology  transfer  medium.  Engineers  who  are 
designing  a new  implementation  of  1553-type  system  or  designing  a 
retrofit  will  find  the  handbook  useful  as  a reference.  Checklists  and 
"considerations"  will  be  useful  in  planning  management  as  well  as 
technical  activities. 

Air  Force  View;  The  handbook  will  forcefully  cover  the  concept  that 
more  interoperability  could  have  been  achieved  among  previous  systems 
than  what  was  achieved.  The  economic  benefits  of  standards, 
specifically  multiplex  interfaces  and  integration  per  1553  will  be 
extolled  with  missionary  zeal.  Imagined,  but  not  real,  difficulties 
of  using  1553  will  be  anticipated  and  addressed.  Air  Force  SPOs  and 
other  agencies  that  fund  and  control  system  development  will  see 
clearly  the  need  for  and  advantages  of  integration  via  1553. 

ADMINISTRATION  OF  THE  HANDBOOK  EFFORT 


The  Air  Force  has  authorized  a period  of  approximately  six  months  for 
the  contractor  to  complete  the  handbook,  including  the  incorporation 
of  comments  from  the  Air  Force.  Following  this,  the  SAE  A2K  Committee 
on  Multiplexing  For  Aircraft  will  be  asked  to  sponsor  and  perform  a 
review  by  industry.  An  acceptable  and  coordinated  handbook  should  be 
available  by  the  fall  of  1979. 


***  Contract  F33615-78-C-0112  awarded  to  The  Boeing  Company;  with  SCI 
Systems  Inc.,  as  subcontractor.  This  paper  was  not  prepared  with 
contract  funds.  Views  expressed  are  those  of  the  author. 
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The  major  sections  of  the  handbook  are: 


Background 
System  Design 
Hardware  Design 

Error  Prevention,  Detection,  Correction 
Software  Architecture 
Multiplex  System  Examples 

The  contractors  have  selected  "principal  investigators"  for  each  major 

section  of  the  book  who  will  be  responsible  to  the  program  manager.  j 

Under  the  leadership  of  the  Multiplex  Applications  handbook  program 
manager,  who  also  ensures  overall  quality  of  the  sections,  the 
principal  investigators  will: 

o Prepare  annotated  outlines  of  each  section; 
o Supervise,  and  prepart  draft  sections; 
o Review  all  sections; 

o Attend  and  support  the  technical  reviews;  and 
o Adjudicate  review  comments  for  their  sections. 

The  Air  Force  supplied  the  outline  for  the  handbook,  and  it  was 
referenced  in  the  technical  tasks  to  be  performed  by  the  contractor. 

See  Appendices  A and  B to  this  paper  (Technical  Tasks,  and 
MIL-STD-1553  Multiplex  Applications  Handbook  Outline) 

DISCUSSION  OF  HANDBOOK  SECTIONS 

The  handbook,  when  prepared,  will  probably  be  300  or  so  pages.  The 
purpose  of  this  discussion  is  to  give  readers  of  this  paper  a "feel" 
for  the  emphases  and  expansions  that  have  been  planned  for  the 
handbook  sections.  The  following  expansions  of  portions  of  the  outline 
carry  the  same  outline  titles  as  Appendix  B to  this  paper.  All  of  this 
is  subject  to  change  as  the  actual  development  of  the  handbook 
progresses. 

II.  Background 

The  background  section  of  this  handbook  is  intended  to  give  the  casual 
reader  and  the  high  level  manager  a feeling  for  the  historical  factors 
which  have  led  to  multiplexing  as  a viable  approach  to  integration. 

This  section  will  address  some  of  the  key  issues  that  lead  to  the 
system  integration  via  multiplexing.  These  include: 

o Need  to  multiplex; 

o Trends  in  avionic  sensors;  i 

o To  what  extent  should  multiplexing  be  used; 


o Is  it  compatible  with  other  multiplexing;  and 
o How  were  the  conclusions  in  the  standard  determined. 

This  section  will  be  at  the  right  level  of  detail,  so  that  an 
interested  reader  will  proceed  into  the  detailed  chapters  and  the 
casual  reader  will  be  satisfied  that  multiplex  is  an  inevitable 
solution  to  his  system  design  problem. 

II.  A.l  Need  for  Multiplexing 

This  section  will  show  that  the  need  for  multiplexing  occurs  in  the 
following  manner: 

o The  need  to  integrate 

- large  penalty  associated  with  dedicated  sensors 

- intercommunication  requirements  high  between  sensors 

o System  performance  (mission  success)  improvements  can  be 

accomplished  using  integration  due  to  redundancy  approaches  now 
available. 

o Standardization  is  achievable  using  the  prescribed  data  bus 
approach . 

o Standardization  provides  sensor  interface  compatibility  reducing 
initial  cost  as  well  as  allowing  system  retrofitting. 

II.  A. 2 Move  from  Analog  to  Digital  Circuits 

This  section  will  provide  a technology  update  on  what  has  happened  to 
avionic  sensors  in  the  past  five  years.  The  discussions  will  show  that 
the  advent  of  microprocessors  for  computation  as  well  as  logic  device 
replacement  has  brought  the  sensors  from  the  analog  world  to  the 
digital  world.  The  technology  survey  will  provide  the  reader  with  the 
following  conclusions: 

o More  sensors  are  becoming  digital; 

o Sensors,  because  of  microprocessor  technology,  are  becoming  more 
capable; 

o Most  sensors  information  can  be  provided  via  a serial  digital  data 
bus  standard;  and, 

o Sensors  using  the  data  bus  standard  integrate  easily. 

II.  B.  Rationale  Behind  Features  of  MIL-STD-1553 

This  section  will  include  an  explanation  of  each  major  section  of  the 
standard  and  rationale  (where  appropriate)  for  the  requirements.  The 


purpose  for  this  section  is: 

o Expand  on  the  explanation  in  the  standard 
o Explain  reasons  for  the  approach;  and, 
o Show  differences  between  1553A  and  1553B 

Currently  we  are  discussing  several  alternatives  to  this  section  of 
the  Background.  One  view  is  that  the  explanation  of  the  very  meaty, 
concise  standard  be  in  a section  after  discussion  of  System,  Hardware, 
and  Software  Design.  This  view  holds  that  those  sections  will  (or 
should)  contain  tutorials  which  will  help  the  reader  understand  the 
rationale.  The  counter  argument  is  that  the  handbook  is  concerned 
with  design  implementation  of  1553,  so  the  rationale  should  be 
presented  initially  so  that  the  requirements  are  firmly  in  mind. 
Another  view  is  that  a tutorial  on  an  information  transfer  system  be 
presented  with  its  physical  and  functional  architectures,  transmission 
media,  and  protocol.  This  will  provide  information  so  that  the  reader 
understands  the  reasons  for  the  choice  of  the  bus,  the  electrical 
characteristics,  and  protocol  requirements  in  the  standard. 

III.  System  Design 

This  section  will  provide  information  to  the  system's  integrator  to 
help  establish  the  level  of  multiplex  integration  required  for  the 
particular  application  being  analyzed.  The  basic  premise  that 
multiplexing  for  integration  is  a viable  cost  effective  technique  has 
been  demonstrated  for  many  vehicles.  Therefore,  the  system 
integrator's  real  problem  is  to  establish  by  analysis  the  proper  level 
of  multiplex  integration. 

III.  B.  Life  Cycle  Cost  Analysis 

The  decision  to  multiplex  must  be  supported  by  objective  life  cycle 
cost  analyses.  Generally  it  is  conceded  that  acquisition  costs  may 
not  be  significantly  reduced  by  data  bus  integration.  It  is  also  well 
known  that  military  airplanes  produced  decades  ago  are  still  in  use, 
having  been  modified  many  times  for  new  missions  and  new 
requirements.  Therefore,  the  level  of  change  activity  after 
acquisition  is  an  important  parameter.  In  the  case  of  multiplexing, 
the  ease  of  modification  usually  shows  LCC  advantages  over 
point-to-point  systems,  even  for  modest  levels  of  change  activity  and 
limited  numbers  of  airplanes.  Production  quantity  may  be  an  important 
factor  in  determining  if  a nonstandard  multiplexing  approach  is  to  be 
used. 

This  section  of  the  handbook  will  identify  the  factors  which  influence 
the  choice  of  multiplex  system  designs;  how  these  factors  affect  LCC; 
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and  paraaeCric  cost  data  on  current  multiplex  system  elements.  The 
section  will  advise  system  designers  to  become  familiar  with  the  LCC 
disciplines,  and  to  seek  the  assistance  of  professionals. 

III.  C.  Architecture  Considerations 

III.  C.2.  Computation/Controller  Locations 

The  bus  controller's  functional  type  will  be  discussed  in  this  section 
including  characterization  of  the  methods  of  bus  control  and  the 
various  types  of  controllers.  The  types  to  be  discussed  include: 

o Systems  that  utilize  a stand-alone  dedicated  bus  controller  that 
performs  all  of  the  required  functions  to  operate  and  maintain  a 
data  bus  system. 

o Systems  that  utilize  general  purpose  computers  performing  system 
integration  functions  and  the  I/O  function  of  bus  control  and 
management . 

o Systems  that  utilize  multiple  general  purpose  computers  to  operate 
as  bus  controllers  as  well  as  perform  specific  system  functions. 

The  bus  control  in  this  case  can  be  dynamically  allocated  to  any 
capable  processor. 

The  understanding  of  these  applications  is  essential  to  the  reader  of 
the  handbook. 

III.  D.  System  Control  Considerations 
III.  D.l.  Bus  Controller  Software 

Software  designers  need  to  understand  the  system  control  methods,  the 
hardware  architecture  and  capabilities  and  the  partitioning  of 
functions  to  processors  before  messages  and  message  pointers  can  be 
constructed.  This  section  of  the  handbook  will  present  the  general 
method  by  which  table  driven  bus  control  software  is  designed,  and 
will  give  several  specific  (but  still  generalized)  message  lists, 
timing  and  control  data  and  the  corresponding  bus  control  software 
design.  With  this  material,  it  will  be  quite  clear  to  the  system 
designer  and  the  software  designer  what  their  interface  is,  and  how  to 
design  bus  control  software. 

III.  E.  Bus  Network  Considerations  (proposed  addition  to  III) 

It  is  suggested  that  this  topic  be  added  to  the  system  design  outline 
because  of  the  substantial  impact  of  bus  network  configurations  on  bus 
error  rate  performance.  In  other  words,  error  rate  is  a function  of 
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the  system  network  configuration  as  well  as  bus  interface  hardware 
designs.  Unfortunately,  bus  error  rate  ^performance  is  not  easily 
predicted  for  a specific  bus  network  because  of  the  many  variables 
affecting  the  quality  of  a waveform  from  the  time  it  is  transmitted  to 
the  time  it  is  received.  These  variables  can  be  broadly  categorized 
as:  (1)  factors  affecting  waveform  integrity  at  any  given  stub  and 
(2)  characteristics  of  the  receiver  affecting  data  reception  at  that 
stub. 

MIL-STD-1553  has  attempted  to  specify  the  more  obvious  characteristics 
which  affect  error  rate  but  difficulty  arises  when  one  tries  to 
specify  such  characteristics  as  the  type  of  receiver  filter  or  sync 
detect  algorithm  required.  Dictating  implementation  of  design  cannot 
be  the  intent  of  the  standard.  Instead,  receiver  interface 
requirements  rather  than  design  have  been  devised  to  "guarantee" 
proper  bus  performance.  New  requirements  are  still  being  added  to 
this  list,  the  most  recent  being  a minimum  shunt  inductance  value 
imposed  on  the  receiver  coupling  transformer,  and  a minimum  waveform 
zero  crossing  distortion  requirement  that  the  receiver  synchronizer 
must  accept. 

M11>-STD-1553A  requires  that  the  multiplex  system  successfully  work 
with  up  to  33  terminals  and  stub  lengths  to  200  feet.  This  section  of 

the  handbook  will  contain  guidelines  to  indicate  the  effects  on 

waveform  distortion  as  the  result  of  bus  configurations.  It  is 
difficult  to  accurately  predict  the  distortion  present  and  the 
resulting  bit  error  rates  to  be  expected  with  existing  empirical 
data. 

Computer  simulations  are  available  to  develop  parametric  data  that 
will  be  used  to  define  the  waveform  distortion  to  be  expected  from  a 

given  configuration.  Data  from  simulations  will  be  reduced  to 

envelopes  of  permissible  cumulative  stub  lengths  and  trunk  lengths. 
Separate  cases  will  be  developed  for  bus  configurations  employing 
transformer  stub  couplers  and  those  that  do  not.  The  data  will  be 
primarily  intended  to  inform  the  reader  of  preferred  bus 
configurations  and  give  him  some  understanding  of  system  sensitivity 
to  stub  and  trunk  lengths. 

IV.  Hardware  Design 

One  of  the  major  problems  facing  the  system  engineer  when  designing 
and  specifying  a multiplex  system  is  the  transition  from  the  standard 
(MIL-STD-1553)  to  equipment  specifications.  The  normal  approach  is  to 
write  a multiplex  system  specification  based  on  an  interpretation  of 
the  standard  in  the  areas  of  system  operational  protocol,  architecture 
and  electrical  interfaces.  Invariably  differences  in  interpretation 
or  opinions  concerning  the  adequacy  of  the  standard  requirements 


result  in  equipment  interoperability  and  interchangeability  problems. 
Also,  the  equipment  engineer  attempting  to  design  hardware  for  use  on 
a variety  of  programs  is  faced  with  the  problem  of  different  interface 
requirements  for  the  various  systems. 

The  handbook  will  provide  the  guidelines  and  trade-offs  which  will  aid 
in  reducing  the  inadvertent  deviations.  This  section  of  the  handbook 
will  address  the  areas  of  hardware  specification,  design  and 
implementation  so  that  the  more  cost  effective  "standard"  hardware  can 
be  developed  and  employ  d in  future  programs  utilizing  a multiplex 
data  bus. 

The  outline.  Appendix  A (Section  IV)  covers  all  items  of  hardware  in  a 
typical  system.  It  is  suggested  that  subparagraph  B,  entitled 
"Stubbing  and  other  considerations  in  laying  out  the  bus",  be  modified 
to  be  "Bus  Coupler  Characteristics".  This  discussion  will  center 
around  the  electrical  characteristics  of  the  bus  network  and  coupler, 
including  the  effect  of  stubbing  on  the  transmitted  signals. 

IV.  A.  Transceiver  Characteristics 

The  transceiver  includes  three  major  elements:  (1)  transmitter,  (2) 
receiver  and  (3)  coupling  network  to  provide  an  interface  with  the 
twisted  shielded  pair  cable.  The  handbook  will  contain  Design  Manual, 
Design  Tips  and  similar  material  usually  available  to  designers, 
specifically  tailored  to  design  of  transceivers. 

IV.  B.  Bus  Coupler  Characteristics 

A great  deal  of  confusion  has  existed  regarding  the  need  for  and 
characteristics  of  a bus  coupler  for  connection  of  the  terminal  to  the 
main  bus.  MIL-STD-1553A  requires  a separate  coupler  box  to  be  used. 
Two  couplers  are  defined:  (a)  isolation  resistors  only  for  a short 
stub  (1  ft.)  and  (b)  transformer  and  isolation  resistors  for  long  stub 
(20  ft.)  connections.  The  proposed  MIL-STD-1553B  requires  a coupler 
with  resistors  and  a transformer  if  a coupling  box  is  used.  The 
transformer  turns  ratio,  is  not  defined  in  1553A  and  1553B  specifies  a 
turns  ratio  range  of  from  1.41:1  to  1.5:1. 

The  handbook  material  will  relate  the  trade-offs  associated  with 
length  of  stubs  and  use  of  couplers.  The  network  configuration 
considerations  will  be  included  in  the  System  Design  Section  (III). 
The  characteristics  of  the  coupler  transformer  required  to  maintain 
signal  integrity  will  be  described.  Coupler  box  design  and  connector 
type  selection  for  EMI  control  will  be  considered. 

V.  Error  Prevention,  Detection,  and  Correction 
V.  A.  Error  Detection 
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Sources  of  errors  within  a given  multiplex  bus  system  can  be  divided 
into  two  separate  categories:  a)  analog  related  errors  primarily 
originating  in  the  tranmission  media,  and  b)  digital  or  functional 
errors  resulting  from  faults  within  terminals.  The  handbook  will 
discuss  these  sources  in  a manner  intended  to  alert  the  reader  to 
various  error  situations  that  are  likely  to  occur  and  describe  the 
impact  on  systerm  performance  of  these  errors. 

V.  B.  Methods  for  Calculating  and  Measuring  Detected  and  Undetected 
Bit  and  Message  Error  Rate 

This  section  will  define  the  terms  bit,  word,  and  message  error  rate 
and  relate  them  to  a multiplex  bus  system.  MIL-STD- 1 553A  requires  a 
receiver  and  one  transmitter  to  operate  in  the  presence  of  burst  noise 
in  a relatively  uncomplicated  bus  configuration.  Problems  of  test 
repeatability  and  test  length  have  resulted.  The  proposed 
MIL-STD-1553B  modifies  the  error  rate  test  to  exclude  transmission 

line  effects  and  has  redefined  noise  to  be  white  Gaussian.  This  type 
of  test  is  viewed  as  a "figure  of  merit"  test  of  the  receiver,  not  of 

a system.  However,  it  has  the  advantage  of  repeatability  and  requires 

a relatively  short  time  to  complete. 

The  handbook  will  describe  the  evolution  of  and  rationale  for  noise 
testing  and  current  attempts  to  standardize  on  a common  concept  of 
error  rate  as  applied  to  and  isolated  receiver. 

Determining  error  rates  of  a bus  system  rather  than  a receiver  is  a 
far  more  encompassing  task.  The  bus  network  section  will  include 

reference  to  noisy  buses  and  give  statistical  indications  of  bus  error 
rates  for  a hypothetical  system,  but  it  should  be  emphasized  that 
predicted  system  word  error  rates  are  only  as  good  as  the  model  used. 
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4.0  TECHNICAL  TASKS 

4.1  The  contractor  shall  review  Appendix  A (Handbook  Outline), 
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MIL-STD-1553A,  proposed  M1L-STD-1553B  (Appendix  B)  and  submit  to  the 
Air  Force  his  proposed  outline  tvo  weeks  after  the  contract  start 
date.  The  outline  shall  list  issues  to  be  covered,  indicate 
sub-issues  to  be  developed,  and  predicted  levels  of  detail  to  be 
expounded.  A technical  review  sMeting  shall  be  held  at  the  prime 
contractor's  facility  three  weeks  after  the  contract  start  date  to 
coordinate  the  outline.  The  multiplex  system  examples  that  the 
contractor  shall  use  in  the  handbook  will  be  agreed  upon  at  this 
meeting. 

^•2  The  contractor  shall  review  DOD  and  industry  programs  using 

MIL-?TD-1553  systems.  The  contractor  shall  also  review  applicable 
studies  on  multiplex  systems  and  hordware.  As  a minimum,  programs 
reviewed  shall  include  the  F-16,  B-1,  DAIS,  F-18  and  LAMPS. 

^.3  The  contractor  shall  produce  the  handbook  in  accordance  with 

Appendix  A. 

5.0  REPORTS,  DATA,  AND  OTHER  DELIVERABLES 

All  reports  are  in  accordance  with  the  Contract  Data  Requirements 
List,  DD  Form  1423,  Attachment  #1. 

6.0  SPECIAL  CONSIDERATIONS 

f) 

6.1  Air  Force  personnel  will  be  available  to  discuss  with  the 

contractor  the  areas  of  philosophy  and  rationale  behind  features  of 
MIL-STD-1553. 

6.2  The  contents  of  the  handbook  shall  be  nonprc>prietarv  .snd  shall 

become  Air  Force  property  upon  delivery. 
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1.0  INTRODUCTION 

The  introductory  material  in  the  handbook  is  required  to  acquaint  the 
reader  with  the  scope  and  purpose  of  the  handbook,  authority  for  the 
book,  status,  and  general  organizational  approach  which  cannot  be 
inferred  from  the  Table  of  Contents.  This  section  will  be  short, 
pertinent,  and  will  serve  to  encourage  the  reader  to  read  the  whole 
book,  or  to  find  the  section  which  relates  to  his  specific  concern. 
The  introduction  will  contain  the  following  subsections: 


1.1 


Purpose 


The  purpose  of  this  handbook  is  to  present  all  of  the  necessary 
guidelines,  trade  offs,  considerations,  and  procedures  for  the 
effective  use  of  MIL-STD-1553. 

1.?  Scope 

This  handbook  is  concerned  with: 

Military  aircraft. 

Digital  serial  multiplexing  using  MIL-STD-1553  as  the 
controlling  standard. 

Differences  between  MIL-STD-1553A  and  1553B  are  included. 


1.3 

Definitions 

This  section  will  help  the  totally  uninitiated  reader  by  presenting  a 
few  terms  that  are  essential  to  understanding  multiplex  technology  as 
applied  to  aircraft. 

2.0 

BACKGROUND 

2.1 

History 

2.1.1 

Vehicle  Integration 

A brief 

historical  overview 

will  be  provided  in 

this  section 

describing  the  vehicles,  their  missions,  and  the  integration  approach 
used.  This  section's  purpose  is  to  show  that  integration  is  a 
necessary  factor  in  aircraft  and  serial  data  bus  integration  is  the 
method  used. 

2.1.2  Standards  Development 

A brief  historical  overview  will  be  provided  in  this  section 
describing  the  military  approach  to  controlling  this  integration  by 
the  development  of  standards.  The  purpose  of  this  section  is  to  show 
that  the  standard  interface  philosophy  which  yielded  MIL-STD-1553  is 
not  new  but  has  been  developing  along  with  the  integration  approach 
and  application. 


2.2  Technical  Trends  to  Multiplexing 

2.2.1  Vehicle  Mission  Performance 

A brief  overview  will  be  provided  to  indicate  the  complex  missions 
being  required  today.  The  purpose  is  to  indicate  the  extensive  use  of 
sophisticated  sensors,  resource  sharing  and  interconnection 
requirements. 

2.2.2  Vehicle  Modifications 

The  purpose  of  this  paragraph  will  be  to  indicate  the  flexibility 
inherent  in  multiplex  system  and  the  continued  requirement  for 
flexibility  in  the  future  for  the  two  types  of  vehicle  modification 
which  occur,  viz:  updating  and  retrofitting. 

These  two  modification  approaches  will  be  examined  where  ths 
modification  involves  systems  with  or  without  multiplex  integration. 

2.3  Issues  Resolved  by  Developing  a Standard 

A discussion  of  the  unique  position  of  the  MIL-STD  as  a standard 
versus  a specification  will  be  discussed. 

2.2.3  Reduction  of  Cost  by  Standardization 

A brief  overview  of  the  DOD's  approach  to  procurement  in  the  area  of 
standards  as  it  applies  to  aircraft  integration  will  be  presented.  The 
purpose  here  is  to  identify  the  reality  and  necessity  of  standards. 

2.2.4  Technology  as  it  Applies  to  Integration 

A brief  technology  overview  will  be  provided  to  show  the  trends  toward 
digitally  intelligent  devices  and  the  potential  this  provides  to  achieve 
a level  of  compatibility  between  sensors  which  is  required  in 
integration.  The  purpose  of  this  is  to  point  the  way  to  the  standard 
selection  process. 

2.3  Issues  Resolved  by  Developing  a Standard 

2.3.1  Application  Areas 

Discussed  will  be  how  the  standard  applies  to  the  real  time  data  transfer 


501 


I 

f 


I 


t 

i 


and  aircraft  system  control  requirements  of  sucfi  subsystems  as 

navigation,  weapon  delivery,  flight  control,  propulsion,  stores 
management,  etc. 

2.3.2  System  Architectures 

2.3.3  Subsystems  Using  Multiplex  System 

The  purpose  of  this  section  is  to  show  that  the  standard  was  developed  to 
satisfy  the  application  and  was  not  arbitrary.  A brief  discussion  of  the 

signal  types  and  characteristics  found  in  aircraft  integration  will  be 
discussed  in  relation  to  estabalishing  a serial  data  bus  standard. 

2.3.4  Degrees  of  Compatibility 

A brief  discussion  on  what  compatibility  is  and  how  it  applies  to  the 
standard.  The  purpose  of  this  section  is  to  indicate  some  of  the  key 

areas  the  standard  identified  to  make  it  useful. 

2.4  Information  Transfer  System  Tutorial 

The  purpose  of  this  section  is  to  show  the  reader  the  reasons  for  the 
choices  of  the  1553  bus  (from  the  types  of  Information  Transfer  Systems),  / 

the  choice  of  the  electrical  characteristics,  and  the  choice  of  the  ( 

protocol . t 


2.4.1  Types  of  Information  Transfer  Systems 

Various  Information  Transfer  Systems  which  are  used  in  the  communication 
of  digital  data  will  be  identified,  and  the  MIL-STD  data  bus  will  be 
related  to  the  group.  These  will  include: 

COMMUNICATION  TYPES  CONFIGURATION  TYPES 

0 simplex  o star 

0 duplex  0 loop 

0 serial  - single  user 

0 serial  - multiple  users 

2.4. 1.1  Physical  Architectures 

This  paragraph  will  contain  a description  of  the  effects  the  aircraft 
physical  characteristics  had  on  the  MIL-STD  design. 
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2. 4. 1.2  Control  Architectures 
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This  paragraph  will  contain  a description  of  the  various  control  schemes 
allowed  by  the  MIL-STD,  centralized  control  and  decentralized  control. 

2. 4. 1.3  Description  of  1553  Architectures 

This  paragraph  will  contain  descriptions  and  discussions  of  the  various 
architectures  which  can  be  developed  using  the  MIL-STD.  These  include: 

0 single  level  - central  control 
0 single  level  - decentralized  control 
0 multi-level  - local  control 

0 multi-level  - central  control 

The  purpose  of  this  section  is  to  show  the  flexibility  of  the  Standard 
and  discuss  the  advantages/disadvantages  of  each  bus  architecture. 

Advantages  of  the  bus  architecture  will  be  explained. 

2.4.2  Types  of  Information  Transfer  System  Communications  and 

Transmission  Media 

2. 4.2.1  Communication  Techniques 

Various  multiplex  communication  techniques  have  been  developed  for 
serial  bus  transmissions.  These  include 

0 Time  Division  Multiplexing  (TDM) 

0 Frequency  Divison  Multiplexing  (FDM) 

0 Space  Division  Multiplexing  (SDM) 

In  the  same  way,  data  encoding  techniques  differ  from  multiplex  system 
to  multiplex  system.  These  include: 

0 Non-return  to  zero  (NRZ) 

0 Bi-Phase 

0 Bi-Phase-Return  to  Zero 

The  purpose  of  this  section  is  to  show  that  the  communication  technique 
for  the  Standard  considered  several  types  before  the  TDM,  Manchester  II 
bi-phase  L was  selected,  and  the  reason  why  the  selected  technique  is 
appropriate  for  military  aircraft. 


2. 4. 2. 2 Requirements  for  Data  Integrity 


A discussion  of  the  aircraft  environment  and  the  reason  for  selection  of 
certain  characteristics  In  the  Standard  to  improve  data  Integrity  will 
be  presented.  These  Include: 

0 Command  and  response  communication 
0 Parity 

0 Lossless  transmission  line 
0 Passive  stubbing 

The  purpose  of  this  section  Is  to  show  that  the  requirements  for  data 
Integrity  In  the  users  environment  Impacted  the  Standard. 

2.4.3  Management  of  the  Information  Transfer  System 

2.4.3. 1 Information  Transfer  System  Control  Requirements 

A discussion  of  the  mechanism  used  to  control  an  Information  transfer 
systen:  with  a serial  data  bus  (no  dedicated  control  lines)  will  be 
presented.  This  section  will  identify  the  need  for,  and  methods  that 
have  been  developed  to  control  functions  such  as  Initiate,  shut-down, 
change  modes,  self  test,  reset,  etc.  Once  these  requirements  are 
identified,  the  method  the  Standard  has  chosen  to  Implement  them  will  be 
discussed. 

The  purpose  of  this  section  Is  to  show  that  the  Standard  has  Implemented 
the  necessary  control  functions  In  a simple  efficient  fashion,  causing 
few  restrictions  to  the  system  designer 

2. 4. 3. 2 Information  Transfer  System  Message  Control  Requirements 

This  section  Is  similar  to  the  above  paragraph,  because  the  requirements 
for  message  Identification  will  be  established  and  the  various  methods 
(message  ID,  word  ID,  parameter  ID,  etc.)  of  accomplishing  these 
requirements  will  be  presented. 

The  purpose  of  this  section  Is  to  show  that  the  approach  taken  by  the 
Standard  Is  a simple  efficient  method,  causing  few  restrictions. 

2.5  Review  and  Rationale  of  MIL-ST0-1553A  and  B 

This  section  will  include  an  explanation  of  each  major  section  of 
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MIL-ST0-1553B  (In  the  order  of  paragraphing  of  the  Standard)  and 
appropriate  rationale  for  the  requirements  Identified. 

The  purpose  of  this  section  Is  to: 

0 Expand  on  the  explanation  In  the  Standard 
0 Explain  reasons  for  the  approach 
0 Identify  differences  between  the  two  versions  (A  & B) 

Major  sections  of  MIL-STD-1553B  that  will  be  discussed  are: 


1. 

Scope 

2. 

Referenced  Documents 

3. 

Definitions 

4.1 

Test  and  Operating  Requirements 

4.2 

Data  Bus  Operation 

4.3 

Characteristics 

4.3.3 

Transmission  Method 

4. 3. 3. 5 

Word  Formats 

4. 3. 3. 5. 1.7 

Optional  Mode  Control 

4. 3. 3. 5. 2 

Data  Word 

4. 3. 3. 5. 3 

Status  Word 

4. 3. 3. 5. 4 

Status  Word  Reset 

4. 3. 3. 6 

Message  Formats 

4. 3. 3. 7 

Intermessage  Gap 

4. 3. 3. 8 

Response  Time 

4. 3. 3. 9 

Minimum  No-Response  Time-Out 

4.4.1 

Common  Operation 

4.4.2 

Bus  Controller  Operation 

4.4.3 

Remote  Terminal 

4.4.4 

Bus  Monitor  Operation 

4.5.1 

Data  Bus  Characteristics 

4.5.2 

Terminal  Characteristics 

Any  subparagt^aphs  within  these  sections  will  be  Included  in  the 
discussion  of  the  1553B  sections  Identified  above,  if  It  Is  not 
separately  identified. 

3.0  SYSTEM  DESIGN 

3.1  Scope  of  the  System  Chapter 

This  paragraph  will  provide  an  Introduction  to  the  system  chapter  by 
presenting:  (a)  a discussion  of  "where"  system  design  ends  and  hardware 
and  software  design  begins;  and  (b)  a discussion  of  the  need  for  other 


topics  in  the  system  chapter  that  do  not  naturally  fall  within  the  scope 
of  other  chapters,  i.e.,  multiplexing  advantages,  life  cycle  cost 
considerations,  as  well  as  the  relationship  of  multiplex  system  design 
decisions  to  a normal  system  acquisition  cycle. 

3.2  Multiplex  Subsystem  Selection  (To  MUX  or  Not  To  MUX) 

This  section  will  provide  Information  to  the  systems  integrator  to  help 
establish  the  need  for  and  the  level  of  multiplex  integration  required 
for  the  particular  application  being  analyzed. 

3.2.1  System  Integration  Simplification 

This  section  describes  the  procedure  and  gives  examples  of  how  the  system 
engineer  goes  about  defining  a proper  level  of  integration  using 
multiplexing.  From  this  point  the  system  integrator  will  be  able  to 
determine  for  an  application  where  multiplex  provides  a simpler 
integration  approach  than  conventional  point-to-point  interconnects. 

3.2.2  System  Test  Simplification 

This  section  describes  the  integration  and  test  procedures  involved  in 
verifying  a multiplex  data  bus  system.  It  will  show  how  the  use  of 
simulation  and  "hot"  laboratory  bench  mockup  provides  extended 
Integration  time,  thus  reducing  the  hardware,  software,  and  integration 
risk. 

3.2.3  System  Updating  and  Retrofiting  Simplification 

This  section  discusses  the  procedure  required  to  retrofit  an  integrated 
system  in  a vehicle.  The  data  bus  integration  approach  will  be  compared 
with  the  more  conventional  point-to-point  techniques  used  in  previous 
years  for  an  example  system.  Since  no  bus  systems  have  actually  been 
retrofit,  only  the  type  of  data  and  typical  examples  can  be  presented 
here  rather  than  actual  cases. 

3.2.4  Documentation  Requirements  and  Improved  Methods 

This  section  discusses  the  documentation  requirements  associated  with 
system  integration  procedures.  In  addition  to  the  documentation 
requirements,  several  automated  methods  will  be  discussed.  These  include 
two  computer  aided  design  tools  which  have  been  developed  in  the  last  few 
years  to  aid  in  the  study  of  multiplex  integration  systems.  These  tools 
have  extensive  documentation  generation  capability. 


^.2.5  Test  Equipment  Interface  Simplification 

This  section  will  review  ground  readiness  test,  inflight  performance 
testing,  and  ground  maintenance  and  repair  test  as  applied  to  the  data 

bus.  The  methods  of  monitoring  bus  traffic,  the  level  of  test 
achievable,  and  the  analysis  of  the  data  collected  will  be  presented  for 
several  general  system  examples.  Convenient  use  of  the  data  bus  by 
flight  test  instrumentation  to  monitor  and  collect  data  on  systems 
involved  in  the  integration  will  be  illustrated. 

3.3  Life  Cycle  Cost  Analysis 

This  paragraph  will  contain  examples  of  LCC  factors  which  are  important 
in  determining  how  much  multiplexing  is  beneficial.  This  section  will 
identify  and  discuss  the  factors  influencing  choice  of  multiplex  system 
designs,  and  advise  system  designers  to  become  familiar  with  the  LCC 

disciplines. 

3.3.1  Cost  Models 

The  models  available  will  be  identified  with  trade  parameter  sets  and 
output  matricies.  This  section  will  inform  him  how  to  propose  system 

alternatives  which  reduce  LCC. 

3. 3. 1.1  Point-to-Point  vs.  Standardized  MUX 
Significant  LCC  drivers  will  be  identified  and  compared. 

3. 3. 1.2  Non-Standard  Multiplexing  vs.  Standardized  Multiplexers 

The  cost  benefits  of  standardization  will  be  identified  and  compared. 

3.3.2  Specific  Cost  Breakdown  for  Typical  Aircraft  Operation 

Examples  and  explanation  of  the  cost  components  in  the  postacquisition 

time  period  for  a typical  aircraft  multiplex  system  will  be  presented. 

3. 3. 2.1  Maintenance 

Maintenance  parameters  will  be  identified. 

3. 3. 2. 2 Logistic  Support 

These  parameters  will  be  identified. 
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3. 3.?. 3 Retrofit 


Parameters  applicable  to  a retrofit  effort  will  be  examined  for 
suitability. 

3.4  Architectural  Considerations 

This  is  an  Introductory  paragraph  to  the  material  that  follows  In 
suparagraphs.  The  flexibility  inherent  in  the  multiplex  data  bus 
approach  to  integration  allows  multiple  system  architectures.  These 
architectural  questions,  and  their  associated  design  alternatives,  (use 
of  redundancy,  location  of  the  controller,  load  splitting)  will  be 
discussed.  The  key  issues  are: 

0 System  architectural  considerations  and  multiplex  data  bus 
standard  flexibility, 

0 Bus  controller  mechanization  and  the  effects  on  system 
operation  and  system  architectural  issues;  and, 

0 Redundancy  as  applied  to  the  interconnection  of  data  paths  - 
concerning  the  number  of  buses  and  the  method  of  redundancy 
used. 

3.4.1  Redundancy 

This  section  will  contain  a discussion  of  the  redundancy  concepts 
associated  with  the  elements  of  the  MIL-STD-1553  data  bus  system. 

3.4.1  Nonredundant  Bus  System 

Risks  of  using  a nonredundant  bus  system  will  be  examined. 

3.4.1  Bus  System  with  Redundant  Data  Paths 

Examples  of  the  different  types  of  bus  redundancy  will  be  presented  as  in 

the  difference  between  the  DAIS  avionics  configuration  and  DAIS  flight  ^ 

control  configuration.  Examples  and  associated  philosophy  and  benefits  I 

will  be  Included  to  aid  in  understanding  redundancy  of  busses.  ^ 

3.4. 1.3  Bus  System  with  Redundant  Data  Paths  and  Controllers  I 

The  remote  terminal  Interface  electronics  area  where  the  level  of  ; 

redundancy  is  a hardware  design  requirements  issue  will  be  discussed 
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alonq  with  the  differences  between  a redundant  transmitter/receiver  and 
the  completely  dual  redundant  Interface. 

3. 4. 1.4  Bus  System  with  Redundant  Data  Paths,  Controllers  and  Remote 

Terminals 

In  addition  to  the  bus  and  the  remote  terminal,  a discussion  of  bus 
controller  redundancy  Is  Included. 

3.4.2  Computational /Controller  Locations 

The  controller's  functional  type  will  be  discussed  In  this  section 
Including  characterization  of  the  methods  of  bus  control  and  the  various 
types  of  controllers.  The  types  to  be  discussed  Include: 

0 Systems  that  have  a stand-alone  dedicated  bus  controller  which 
performs  all  of  the  required  functions  to  operate  and  maintain 
a data  bus  system. 

0 Systems  that  use  general  purpose  computers  performing  system 
Integration  functions  and  the  I/O  function  of  bus  controller 
and  management. 

0 Systems  that  use  multiple,  general  purpose  computers  to 
operate  as  bus  controllers  as  well  as  perform  specific 
system  functions. 


3.4.3  Load  Splitting 

This  Is  an  Introductory  paragraph  to  the  material  that  follows  in  the 
subparaqraphs . The  data  presented  in  this  section  of  the  handbook  win 
give  the  reader  guidelines  for  establishing  partitioning  of  function  and 
the  number  of  busses.  Once  these  guidelines  are  used,  quantitative 
results  can  be  obtained  using  computer  aided  design  tools.  Some  of  the 
anticipated  guidelines  Include: 

0 Subsystem-unique  requirements 
0 Communication  requirements 
0 Signal  criticality 
0 Level  of  redundancy 
0 Processing  requirement 

0 Channel  capacity  (with  respect  to  real-time) 
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These  guidelines  and  the  rationale  for  them  will  provide  the  system 
designer  and  systems  software  designer  assistance  to  achieve  a consistent 
approach  to  system  architectural  partitioning. 

3. 4. 3.1  Dual  Bus  System 
Advantages  are  discussed. 

3. 4. 3. 2 Multi-Bus  System 
Advantages  are  discussed. 

3. 4. 3. 3 Separate  Buses 

Advantages  and  current  examples  are  discussed. 

3.5  System  Control  Considerations 

System  control  is  related:  (a)  to  the  architecture  considerations;  (b)  to 
the  partitioning  of  the  bus  control  hardware  and  software;  (c)  to  the 
allocation  of  control  among  processing  elements;  and,  (d)  the  allocated 
system  performance  requirements,  i.e.,  what  is  expected  of  the  integrated 
system  of  sensors,  processors,  controls,  displays,  etc.  This  section  of 
the  handbook  will  provide  the  appropriate  introduction  and  synthesis  of 
all  system  control  considerations. 

After  this  general  discussion  of  system  control,  an  introduction  to  the 
subtopics  (bus  control  software,  bus  message  protocol,  error  detection 
and  correction)  of  the  section  will  be  presented. 

3.5.1  Bus  Controller  Software 

The  requirements  and  source  of  information  for  the  "table"  in  table 
driven  bus  control  software  will  be  presented  and  related  to  system 
control  design. 

3.5.2  Bus  Message  Protocol 

This  section  will  discuss  various  types  of  data  traffic  to  be  expected  in 
an  integration.  Data  traffic  and  the  associated  message  characteristics  (■ 

are  a function  of  the  following  system  factors: 


I* 
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Mission  Profiles, 
Sensors,  and 
Application  Software. 


3. 5.2.1  Synchronous  and  Asynchronous  Messages 

Messacie  traffic  associated  with  a typical  system  will  be  described  in 
terms  of  the  synchronous  and  asynchronous  traffic  it  requires.  The 
method  for  handling  this  traffic  using  the  MIL-STn-1553  message  formats 
I will  be  detailed. 

3.5.?.?  Abnormal  Requests 

1 

t In  addition  to  the  system  data  traffic,  the  multiplex  data  bus  system 

requires  certain  messages  to  manage  itself.  These  involve: 

j 

' System  event  announcements  - asynchronous. 

I Error  test  - synchronous  and  asynchronous. 

I Error  recovery  - asynchronous. 

j In  this  area  the  handbook  will  discuss  the  use  of  the  mode  codes,  status 

I bits,  and  error  recovery  procedures  as  they  apply  to  the  system 

, integration. 

I 3.5.3  Error  Detection  and  Correction 

j 3.5.3. 1 Bit  Error  Rates 

t 

An  analysis  of  bit  error  rates  and  bus  utilization  efficiency  is  required 
I to  support  mission  requirements  for  any  weapons  system.  The  effect  of 

bit  errors  and  an  indication  of  acceptable  error  rates  are  discussed  for 
* several  system  functions  and  sensors. 

j 3.5.3.?  Error  Detection  Theory 

t 

^ A siirple  analogy  will  be  used  to  demonstrate  the  capability  of  the  parity 

I check,  the  check  sum,  and  detection  and  correction  codes.  The  detailed 

r theory  is  referenced  but  specific  performance  examples  are  given  with 

I sufficient  explanation  of  all  errors  to  enable  the  reader  to  understand 

i how  the  bit  error  rate  for  the  standard  data  bus  can  be  improved  for 

[ critical  data  with  minimum  effect  on  bus  efficiency. 


I 
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3. 5.3.3  Monitoring  the  MUX  Bus  State  of  Health 

The  extent  of  bus  monitoring  is  dependent  upon  its  purpose  within  the 
system.  In  the  handbook,  the  reader  will  be  apprised  of  current 
monitoring  techniques  available  at  present  and  their  limitations. 

3.5.4  Pre  and  Post  Flight  Checkout 

This  section  of  the  handbook  will  describe  how  special  system  modes  which 
can  control  the  pre  and  post  flight  checkouts  are  created  and 
incorporated  into  the  system.  The  following  tasks  or  modes  are  discussed: 

a.  Performance  preflight  go/no-go  avionics  check 

b.  Determine  RT  status 

c.  Record  system  errors  for  maintenance  purposes 

3.6  Bus  Network  Considerations 

The  substantial  effect  of  bus  network  configurations  on  bus  error  rate 
performance  will  be  treated  in  this  section.  In  other  words,  error  rate 
is  a function  of  the  system  network  configuration  as  well  as  bus 
interface  hardware  designs.  However,  bus  error  rate  performance  is  not 
easily  predicted  for  a specific  bus  network  because  of  the  many  variables 
affecting  the  quality  of  a waveform  from  the  time  it  is  transmitted  to 
the  time  it  is  received.  These  variables  can  be  categorized  as:  (1) 
factors  affecting  waveform  integrity  at  any  given  stub,  and  (2) 
characteristics  of  the  receiver  affecting  data  reception  at  the  stub. 
The  results  of  computer  simulations  will  be  presented  to  aid  the  system 
designer  in  getting  insight  into  the  influence  of  the  variables. 

The  considerations  in  specifying  the  data  bus  wire  and  connectors  will 
also  be  included  in  this  section. 

3.7  Multiplex  System  Design  in  the  System  Acquisition  Life  Cycle 

The  purpose  of  this  section  is  to  relate  the  multiplex  system  design 
considerations  and  decisions  to  a normal  system  acquisition. 

3.7.1  Conceptual  Phase 

This  paragraph  will  discuss  the  relationship  of  studies  of  proposed 
solutions  of  systems  for  satisfying  a military  need,  required  operational 
capability,  etc.  to  integration  using  MIL-STD-1553.  The  level  of  detail 
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to  which  an  Initial  system  specification  establishes  and  defines  the  role 
and  method  of  integration  via  multiplex  buses  will  be  discussed. 

3.7.2  Validation  Phase 

This  is  the  period  when  major  system  characteristics  are  refined  through 
studies,  system  engineering,  and  preliminary  definition  of  the  multiplex 
system.  It  may  also  include  prototype  or  brassboard  development,  test, 
and  evaluation.  From  these  efforts,  an  authenticated  system 
specification,  and  preliminary  development  specifications  (both  Cl  and 
CPCI)  result. 

This  paragraph  will  relate  the  general  way  that  studies  of  operational 
needs,  system  reguirements  (e.g.,  for  data  communication  and  transferl, 
and  system  optimization  may  affect  the  definition  of  a multiplex  system. 

3.7.3  Full  Scale  Development  Phase 

In  a normal  system  acguisition,  the  extent  of  integration  using  the  data 
bus  is  defined  prior  to  the  start  of  FSD,  but  many  of  the  details  of  the 
Integration  remain  to  be  defined  and  developed. 

This  paragraph  will  present  the  general  chronology  of  FSD  to  multiplex 
system,  hardware  and  software  specification,  development,  and 
verification.  The  scope  of  formal  PDRs  and  CDRs  will  be  included,  to 
provide  guidance  for  the  level  of  detail  and  the  questions  to  be  answered 
at  those  reviews. 

The  need  for,  and  description  of  testing  (laboratory,  "hot  bench", 
ground,  and  flight)  as  it  relates  to  multiplex  systems  will  be  included. 

4.0  HARDWARE  DESIGN 

4.1  Multiplex  Terminal  Functional  Partitioning 

r 

; This  subsection  will  provide  a generalized  description  of  multiplex 

terminal  functional  elements  and  considerations  for  partitioning  which 
apply  to  remote  terminals,  bus  controllers  and  monitors.  a brief 
description  of  remote  terminals,  bus  controllers  and  monitors  related  to 
typical  system  operation  will  be  presented  for  introduction  to  this 
section. 


t 
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MIL-STD-1553  A/B  Requirements  Summary 

This  subsection  will  provide  a summary  and  comparison  of  MIL-STO-1553  A/B 
requirements  which  have  significant  effect  on  the  terminal  hardware 
design,  especially  at  the  bus  interface.  Special  consideration  will  be 
given  the  key  characteristics  of  signal  levels,  waveform,  noise  and 
loading  effects  at  the  bus/terminal  input/output  port.  The  effects  of 
stubbing  from  the  trunk  to  the  terminal  will  be  briefly  reviewed  to  show 
why  external  couplers  may  be  required  to  maintain  signal  integrity  and 
fault  isolation  characteristics  of  the  bus  network.  A discussion  of 
shielding  and  grounding  techniques  for  EMI  control  will  be  presented.  A 
detailed  review  of  network  configuration  and  effects  on  signal  integrity 
is  contained  in  Section  III. 

Test  and  evaluation  criteria  will  also  be  considered  in  the  summary. 

4.3  Bus  Coupler  Characteristics 

The  key  characteristics  of  the  external  bus  coupler  will  be  described  in 
the  following  paragraphs 

4.3.1  Transformer  Characteristics 

The  following  characteristics  of  the  coupler  transformer  will  be 
considered. 

0 turns  ratio 
0 impedance 
0 droop  characteristic 
0 shunt  inductance 

0 common  mode  rejection  f? 

K 

4.3.2  Packaging 

This  section  will  describe  the  physical  properties  of  various  couplers. 

The  imoortant  considerations  include  size,  shielding,  grounding  and 
mounting  provisions.  In  addition,  the  selection  of  connectors,  if  used, 
will  be  discussed. 

4.4  Transceiver  Characteristics 

4.4.1  Overall  Considerations 

The  general  functional  characteristics  and  the  considerations  for 
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transceiver  design  related  to  the  Mil-Standard  requirements  will  be 
listed  and  discussed. 

4.4.2  Transmitter  Design 

The  following  areas  will  be  considered  for  their  impact  on  transmitter 
design  and  performance: 

0 output  signal  waveform  and  power 
0 voltage  or  current  drive 
0 output  impedance 
0 transformer  characteristics 
0 fault  protection  and  control 
0 noise 

0 technology  and  packaging 

4.4.3  Receiver  Design 

The  major  factors  affecting  receiver  design  are  listed  below  and  will  be 
considered  in  this  discussion: 

0 filter  selection/design 
0 detection  methods  (analog/digital) 

0 receiver  threshold/noise/error  rate 
0 transformer  characteristics 

0 technology  and  packaging  (existing  and  planned  devicves) 

4.5  Remote  Terminal  Design 

4.5.1  RT  Functional/Physical  Partitioning 

The  remote  terminal  will  be  partitioned  to  identify  the  functions  that 
must  be  performed  in  various  classes  of  applications.  The  basic 
functions  will  be  described  and  considerations  for  physical  partitioning 
and  implementation  reviewed. 

4.5.2  RT  Design  Examples 

Examples  of  RT  designs  and  implementations  will  be  described.  These 
examples  will  span  the  range  of  RT  types  from  stand-alone  with  extensive 
subsystem  signal  conditioning  to  the  transparent  word  processor 
interfacing  with  an  intelligent  subsystem  processor. 
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4.fi  Bus  Controller  Design 

4.6.1  Controller  Functional/Physical  Partitioning 

The  controller  functions  will  be  identified  and  considerations  for 
physical  partitioning  and  implementation  will  be  reviewed. 

4.6.2  Controller  Design  Examples 

Examples  of  controller  designs  varying  from  stand-alone  and  flexible 
(programmable)  computer  interface  to  simple  bus  interface  (word 
processor)  will  be  described. 

4.7  Bus  Monitor  Design 

4.7.1  Monitor  Functional  Partitioning 

Monitor  functions  will  be  identified  and  possible  combinations  of  these 
functions  will  be  described. 

4.7.2  Monitor  Design  Examples 

Examples  of  monitor  designs  resulting  from  various  operational  systems 

requirements  will  be  detailed. 

4.8  Advanced  Technology  Implementation 

A discussion  of  circuit  and  packaging  technology  available  for  multiplex 
terminal  implementation  will  be  described.  Current  state  of  the  art 
devices  and  those  expected  to  be  available  in  the  near  future  will  be 
identified.  An  evaluation  will  be  presented  to  show  the  possibilities 
for  application  of  advanced  hybrid  and  LSI  technology  to  future  terminal 
designs. 

5.0  SOFTWARE  ARCHITECTURE 

5.1  System  Control  Philosophies 

Several  different  system  control  philosophies  will  be  outlined  in  this 
section  (paragraph  5.1)  to  provide  a basic  set  of  concepts  which  can  be 
compared  with  respect  to  the  points  outlined  below.  This  section  on 
control  philosophies  establishes  the  understanding  for  Sections  5.2  and 
5.3  (Control  of  Application  Software  and  Application  Software  Design 
Considerations). 
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5.1.1  Contrast  Control  Procedures  with  Requirements 

Requirements  on  a data  processing  system  such  as  redundant  processing  of 
data,  cyclic  frequency  of  updated  data,  allowable  latency  of  data,  etc. 
will  affect  the  choice  of  a control  philosophy.  How  the  control 
mechanisms  impact  a variety  of  requirements  and  vice  versa  will  be 
discussed. 

5.1.2  System  Synchronization 

The  synchronization  of  the  software  functions  plays  an  important  part  in 
the  control  of  most  systems.  Each  control  philosophy  may  have  different 
mechanism  whereby  the  software  functions  can  be  synchronized  in  a 
distributed  system. 

,5.1.3  Allocation  of  Control 

The  function  of  "who  is  in  control"  and  "how  to  establish  the  control" 
state,  initially,  and  during  any  reconfiguration  varies  by  control 
procedure  and  is  a subject  frequently  glazed  over  by  designers. 

5.1.4  System  Error  Handling  and  Recovery 

The  mechanism  for  error  recovery  depends  both  on  the  control  procedures 
and  upon  the  requirements  imposed  upon  the  system.  For  example,  triple 
redundant  flight  controls  error  handling  would  be  significantly  different 
from  error  handling  for  functionally  redundant  units.  The  control  design 
has  a significant  impact  on  how  these  functions  will  be  monitored  for 
correct  functioning  and  how  recovery  will  occur  once  an  error  has  been 
detected.  The  following  subtopics  will  be  discussed: 

a.  Mechanisms  to  monitor  the  multiplex  system  for  proper 
functioning 

b.  Error  detection 

c.  Error  isolation 

d.  Error  recovery  techniques. 

5.2  Control  of  Application  Software  in  a Multiplex  System 

5.2.1  Master  Executive  Control  Function 

The  executive  functions  are  related  to  the  multiplex  control  philosophy, 
and  this  will  be  explained.  The  importance  of  making  the  executive 
independent  from  the  system  control  will  be  highlighted.  Then  the 
functions  of  the  master  executive  will  be  discussed,  organized  as  follows: 
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since  bus  control  is  a function  of  the  master  executive,  bus  control 
software  will  be  thoroughly  described.  The  general  method  by  which  table 
driven  bus  control  software  Is  designed  and  the  functions  of  message 
lists  will  be  related  to  bus  control  software  design. 

5.2.?  Local  Executive  Control  Function 

The  duties  of  a local  executive  In  a processing  element  will  be  defined 
and  discussed. 

5.2.3  Relationship  with  System  Control 

The  coupling  of  the  control  procedures  with  the  executive  functions  will 
be  explored  and  described.  The  function  of  the  local  executive  with 
respect  to  system  synchronization  will  be  established  here. 

5.2.4  Method  of  Facilitating  Applications  Communications  over  the  MUX 

The  specific  schemes  to  allow  the  tasks  of  one  processor  to  communicate 
and  to  control  tasks  in  another  processor  will  be  discussed  in 
conjunction  with  the  desirability  of  allowing  multi -computer  task 

coordination. 

5.2.5  Local  Error  Control 

The  errors  which  the  local  executive  is  tasked  with  recovering  will  be 
discussed.  Techniques  and  impacts  on  the  system  error  control  will  be 

expanded  here  from  the  discussion  In  system  error  handling  and  recovery. 

5.3  Application  Software  Design  Considerations 

5.3.1  MUX  Impact  on  Application  Software 

Application  software  organization  and  design  is  impacted  because  of  the 
physical  distribution  of  functions  over  multiple  processors  and  the 

information  transfer  system  capabilities  and  restrictions.  The 

relationship  between  the  multiplexing  of  information  transfers  and  the 

application  software  will  be  discussed. 

5.3.2  Independence  of  Modules 

A design  goal  of  all  software  is  to  construct  modules  which  are  maximally 
Independent.  The  greater  importance  of  module  independence  will  be 

described  as  it  relates  to  the  desirable  goal  of  being  able  to  move  a 

module  from  one  processing  element  to  another  to  redistribute  the  \ 
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processing  load  for  a distributed  processing  system.  The  general 
techniques  for  contruction  of  software  will  referenced  in  this  section. 

5.4  Support  Software 

While  most  of  the  support  software  is  common  between  a multiplex  system 
and  any  other  computer  system,  communication  via  messages  between  one 
precessing  element  and  another  will  have  an  impact  on  the  support 
software.  Synchronous  messages,  their  frequency,  source  and  destination, 
processor  location  and  impact  of  arrival  of  the  message  can  be  automated 
for  incorporation  into  the  total  system.  The  effects  and  utility  of 
specialized  tools  to  facilitate  software  development  will  be  described. 

6.0  MULTIPLEX  SYSTEM  EXAMPLES 

The  candidate  systems  that  will  be  described  in  this  section  have  been 
chosen: 


B-5?  Offensive  Avionics  System 
F-16  Avionics 
F-18  Avionics 
LAMPS 

Advanced  Attack  Helicopter 
Oiqital  Avionics  Integration  System 

Final  selection  will  be  based  on  the  following  criteria: 

0 Current  state-of-the-art  application  in  aircraft  subsystems. 

0 Utilization  of  MIL-STD-1553  or  very  similar  requirements. 

0 Long  term  system  utilization  which  requires  extensive 
retrofit. 

0 Availability  of  system  design  details,  including  rationale 
for  characteristics  selection. 

0 Variety  of  subsystem  applications  (AMUX,  EMUX,  Stores, 
management.  Flight  control,  communications  control,  etc.) 

The  following  is  a preliminary  approach  to  the  major  subjects  to  be 
discussed  in  this  section  with  a listing  of  information  content. 

6.1  Selection  of  Examples 

0 Criteria  for  selection 
0 Information  sources 
0 Listing  of  examples/brief  description 
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6.?  - 6.7  Examples  #1  Description 


I 

1 


(All  example  paragraph  headings  are  identical  to  those 
given  below: 

6.x. 1 Application  Area 

0 (EMUX,  AMUX,  Stores  Management,  Flight  Controls,  etc.) 
0 Extended  application 

0 Type  of  information/control  signals  transmitted 
0 Signals  (Parameters) 

0 Subsystem  equipments 
0 Unique  requirements 
6.X.?  System  Architecture 

0 Physical /functional 

0 Documentation/comparison  to  MIL-STD-1553A/B 
0 Deviations  from  MIL-STD 
0 Redundancy  level /type 

0 Bus  network/length/stubbing/couplers/limitations 
0 Synchronization  method 
0 Bus  protocol 
0 Message  size 

6.X.3  System  Control 

0 Fault  isolation  and  reconfiguration 
0 Primary/backup  control 
0 BITE 
0 Software 
0 Unique  modes 

6.x. 4 Bus  Controller 

0 Primary/backup 
0 Software/firmware  control 
0 Flexibility 

0 Controller  subsystem  type 
0 Self  test 
0 Reconfiguration 

6.x. 5 Remote  Terminal 

0 Locations/types 
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0 Integral  to  subsystem  or  standalone 
0 Subsystem  Interface 
0 Redundancy  level/reconfiguration 
0 Control  of  faulty  transmitter 
0 Self  test  and  fault  Isolation 
0 Size/we1ght/power 
0 Device  technology 
0 Unique  features 

6.x. 6 Rationale  for  System  Design 

0 Hardware 
0 Software 

0 Network/couplers/stubbing 
0 Signals  included/excluded 
0 Redundancy  level 
0 Waveform 
0 Grounding/shielding 
0 BITE  level 
0 ERROR  rate  tolerance 

0 Deviations/additions/deletions  from  MIL-STD 


A COMPARISON  OF  TIME  DIVISION  MULTIPLEX  DATA  BUS 


TECHNIQUES  BASED  ON  DATA  TRANSFER  PERFORMANCE 
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Bedford,  Massachusetts 


ABSTRACT 

This  paper  compares  the  performance  of  three  time  division  multiplex  bus 
techniques  based  on  data  transfer  efficiency.  The  sensitivity  of  the  data 
handling  capability  of  each  of  these  multiplex  bus  techniques  to  a series  of 
parameter  variations  is  examined.  These  parameters  include  bus  operating 
frequency,  data  message  length,  the  interword  and  intermessage  gaps  between 
transmissions,  and  the  number  of  active  terminals  employed  in  the  bus  system. 
The  results  of  this  parametric  examination  describe  the  upper  bound  of  data 
transfer  performance  for  each  of  the  TDM  bus  techniques. 

INTRODUCTION 

The  purpose  of  this  paper  is  to  present  the  results  of  a series  of  para- 
metric studies  designed  to  investigate  the  upper  bound  on  data  transfer 
performance  for  several  time  division  multiplex  bus  techniques.  To  accomplish 
this  task,  three  bus  protocol  techniques  were  examined.  Each  of  the  selected 
bus  techniques  examined  in  this  study  is  either  currently  in  use,  or  is  being 
considered  as  a candidate  for  application  to  military  avionics  information 
distribution  systems. 

The  first  bus  arbitration  technique  examined  uses  the  command-response 
protocol  as  described  in  MIL-STD-1553A  (Reference  1).  This  technique  and 
standard  has  been  extensively  employed  in  a series  of  Air  Force  Avionics  Pro- 
grams. The  second  system  examined  investigates  a data  bus  constrained  to  the 
Pol led-Contention  arbitration  technique  as  describeS  in  MIL-G-85013  (AS) 
(Reference  2).  This  format  and  protocol  was  developed  by  the  Navy  Air 
Development  Center  and  is  normally  referred  to  as  the  General  Purpose  Multi- 
plex System  (GPMS)  format.  The  GPMS  architecture  has  been  examined  for 
military  applications  in  both  shipboard  and  avionics  systems.  The  third  bus 
arbitration  technique  examined  is  a pure  contention  protocol,  and  is  imple- 
mented in  a system  configuration  called  the  Listen-While-Talk  System.  The 
Listen-While-Talk  (LWT)  technique,  under  investigation  at  The  MITRE  Corpor- 
ation, has  been  applied  to  several  ground-based  information  transfer  systems 

* This  paper  released  under  the  sponsorship  of  the  Electronics  Systems 
Division  of  the  Air  Force  Systems  Command. 
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and  is  currently  being  examined  as  a possible  candidat  for  an  Air  Force 
Avionics  Bus  Program. 


In  this  paper,  the  upper  bound  on  bit  transfer  rates  and  information 
transfer  efficiency  will  be  examined  under  the  conditions  imposed  by  the 
applicable  standards,  and  then  these  results  will  be  examined  under  condi- 
tions where  some  of  the  constraints  imposed  by  those  standards  were 
modified.  The  interest  in  evaluating  modifications  to  the  existing  para- 
meters is  driven  by  the  possible  use  of  fiber  optics.  Existing  standards 
call  for  the  use  of  twisted  shielded  pair  cable  as  the  transmission  medium 
and  this  factor  limits  the  bus  operating  frequency  to  the  1 Megahertz  region. 

The  use  of  fiber  optics  removes  that  data  rate  restriction  and  bus  operation 
frequencies  up  to  10  Megahertz  has  already  been  demonstrated  (Reference  3). 

In  this  report,  the  data  transfer  capability  of  the  system  was  examined  at 
data  rates  between  1 Megahertz  and  10  Megahertz.  The  sensitivity  of  data 
transfer  capability  to  changes  in  the  interword  gap  was  investigated,  as  well 
as  the  effects  of  variations  in  interword  gap.  An  examination  of  variations  P 

in  interword  gap  on  data  transfer  efficiency  and  information  transfer 
capacity  over  the  range  of  2 to  10  microseconds  was  also  included  in  this 
study.  The  system  characteristics  and  data  transfer  performance  of  the  three 
selected  systems  were  coirpared.  This  comparison  indicates  the  sensitivity 
of  each  of  the  protocol  techniques  to  variations  in  bus  parameters  and  de- 
scribes the  advantages  of  one  bus  technique  over  the  others  in  areas  where 
this  is  applicable.  | 

MIL-STD-1553A  CONFIGURATION  j 

The  document  MII.-STD-1553A  describes  a coimand- response  bus  protocol  ' 

designed  to  allow  internal  conmuni cations  of  digital  messages  within  an  ^ 

aircraft.  The  basic  Command-Response  architecture,  described  in  MIL-STD- 
1553A,  is  shown  in  Figure  1.  Two  types  of  terminal  units  are  available  in 
this  configuration;  remote  terminals  and  the  bus  control  interface  terminal. 

At  any  one  time  there  is  only  one  active  bus  controller  and  all  other  termi- 
nals are  considered  remote  terminals.  ■ 

In  this  conmand-response  configuration  all  coimands  originate  at  the 
bus  controller.  The  bus  controller  can  initiate  three  types  of  commands: 

Remote  Terminal  to  Control  Processor  Data  Transfers,  Control  Processor  to 

Remote  Terminal  Data  Transfers  and  Remote  Terminal  to  Remote  Terminal  Data  r 

Transfers.  It  should  be  noted  that  the  Remote  Terminal  to  Control  Processor  ' 

and  Control  Processor  to  Remote  Terminal  Modes  require  the  same  number  of  '■ 

overhead  words  to  achieve  each  data  transfer,  so  only  one  of  these  modes  will 

be  analyzed  in  this  paper.  This  mode  will  be  abbreviated  as  the  CU/RT  ' 

(Control  Unit  to  Remote  Terminal)  mode.  The  other  mode  to  be  analyzed  is  the  \ 

Remote  Terminal  to  Remote  Terminal  mode  and  will  be  abbreviated  as  the  RT/RT 

mode.  The  RT/RT  mode  is  a matched  pair  of  CU/RT  transfers.  The  controller  , 

first  requests  the  receiving  remote  terminal  to  listen  and  then  asks  the 

sending  remote  terminal  to  transmit.  During  the  exchange  of  data,  both 

remote  terminals  respond  with  a status  word  at  the  proper  time. 
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Figure  2 


Effects  of  Parameter  Variations  on  Information  Transfer  Efficiency 
(Command-Response  Protocol) 
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In  the  word  format  employed  in  MIL-STD-1553A  with  the  transmission  of 
each  data  word,  3 bits  of  sync  and  one  bit  of  parity  is  transmitted.  These 
bits  must  be  considered  along  with  the  overhead  produced  by  the  command  and 
status  words  when  establishing  maximum  information  data  transfer  rates  and 
the  effective  bus  operating  efficiency. 

A plot  of  the  upper  bound  on  data  transfer  efficiency  for  a bus  con- 
strained to  this  command-response  protocol  and  format  is  shown  in  Figure  2. 

In  this  diagram,  the  information  transfer  sensitivity  of  the  remote  terminal 
to  remote  terminal  transfer  mode  is  illustrated  for  various  values  of  inter- 
word gap,  bus  operating  frequency  and  the  number  of  words  transferred  per 
message.  This  figure  illustrates  that  for  a fixed  number  of  words  transferred 
per  message,  the  information  transfer  efficiency  will  decrease  for  increasing 
values  of  interword  gap  and  bus  operating  frequency. 

NAVY  GPMS  CONFIGURATION 

A typical  polled  contention  architecture  of  the  type  used  in  GPMS  is 
shown  in  Figure  3.  For  the  analysis  done  in  this  report,  only  a one  bus 
configuration  was  considered.  In  a one  bus  configuration  the  system  compo- 
nents would  consist  of  the  data  bus,  a polling  controller  and  a series  of 
polled  terminals.  The  polling  controller  acts  only  as  an  independent  bus 
arbitrator.  The  bus  controller  offers  the  available  bus  to  each  interested 
polled  terminal,  in  turn,  with  the  addressed  polled  terminal  accepting  the 
bus  with  a message  available  or  message  request  signal  if  interested,  or  not 
responding  if  no  message  is  to  be  transferred.  The  polled  contention  system 
can  act  in  two  modes:  where  the  polled  terminal  accepting  the  channel  offer 
is  a data  sink  or  where  the  polled  terminal  accepting  the  channel  offer  is  a 
data  source.  The  protocol  for  this  system  requires  a minimum  of  three  over- 
head words:  the  bus  offer,  message  available,  and  message  request,  to 
initiate  the  transfer  of  a data  message  to  a second  terminal.  In  the  case 
where  the  polled  terminal  accepting  the  channel  offer  is  a data  sink,  only 
two  overhead  words  are  required  to  initiate  a data  transfer. 

This  investigation  was  based  on  a single  bus  GPMS  configuration,  whet^ 
for  every  request  there  is  a response.  In  a standard  mechanization  of  this 
type  of  bus  system,  several  independent  busses  may  be  employed  to  provide 
active  redundancy.  If  these  busses  are  supported  by  non-blocking  terminals, 
the  results  of  this  examination  can  be  extrapolated  to  establish  the  upper 
bound  on  bit  transfer  rates  for  these  multiple  bus  configurations. 


In  moving  information  from  one  terminal  to  another,  the  upper  bound  or 
data  transfer  performance  will  be  established  by  the  way  the  data  is  blocked, 
the  overhead  associated  with  each  data  word  transfer  and  the  overhead 
required  to  establish  message  comnwni cations.  The  data  word  format  used  in 
this  pol led-contention  mechanization  is  identical  to  the  data  word  employed 
in  MIL-STD-1553A. 
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The  effects  of  parameter  variations  on  information  transfer  efficiency, 
for  the  mode  where  the  terminal  accepting  the  bus  offer  is  a data  source, 
is  shown  in  Figure  4.  It  can  be  seen  from  this  figure  that  information 
transfer  efficiency  is  sensitive  to  bus  operating  frequency,  the  interword 
gap  and  the  nuitter  of  words  transferred  per  message. 

LISTEN-WHILE-TALK  CONFIGURATION 

The  Listen-While-Talk  system,  or  LWT,  is  a pure  contention  system  utili- 
zing no  central  control  element,  and  the  system  provides  distributed  network 
control.  Contention  protocols  have  been  used  in  the  past  in  an  effort  to 
make  more  efficient  use  of  available  bandwidth  for  computer  and  terminal 
communications.  They  take  advantage  of  the  low  duty  cycle  or  the  "bursty" 
nature  of  data  normally  e .changed  between  terminals  and  computers.  Given  a 
large  number  of  bursty  users,  the  contention  protocol  uses  the  law  of  large 
nunbers  to  provide  sufficient  bandwidth  to  match  the  average  aggregate  data 
transmission  rate  of  the  entire  population,  rather  than  matching  the  peak 
rate  of  each  device. 

The  LWT  contention  technique  developed  at  The  MITRE  Corporation  is  an 
outgrowth  of  the  ALOHA  System  developed  at  the  University  of  Hawaii,  and  the 
Ethernet  System  developed  by  the  Xerox  Corporation. 

The  LWT  contention  system,  as  currently  mechanized  at  The  MITRE  Corpor- 
ation is  shown  in  Figure  5.  The  system  consists  of  an  "outbound  cable"  for 
data  transmission  and  an  "inbound  cable"  for  data  reception.  This  uni- 
directional concept  allows  the  receiver  at  each  tenninal  to  listen  to  all 
other  possible  transmissions  on  the  line  while  that  terminal  is  transmitting. 
A terminal  wishing  to  transmit  first  monitors  the  status  of  the  line.  If 
no  other  units  are  transmitting,  the  terminal  initiates  transmission. 

Because  of  the  relative  positions  of  various  transmitters  and  receivers  in 
the  system,  two  terminals  may  decide  to  initiate  transmissions  almost  simul- 
taneously, and  the  propagation  delay  of  the  line  would  allow  each  to  have  an 
essentially  clear  channel  at  the  initiation  of  transmission;  hence  the 
Listen-While-Talk  requirement.  After  initiation  of  the  transmission,  the 
receiver  is  required  to  monitor  the  line  for  conflicts  with  other  trans- 
mitters for  at  least  a time  period  corresponding  to  the  longest  possible 
propagation  delay  in  the  system.  If  no  conflicts  occur,  transmission 
continues.  If  a conflict  occurs,  both  conflicting  terminals  will  observe 
the  phenomena,  and  both  terminals  will  cease  transmission.  Since  there  is  no 
central  control  point  to  arbitrate  who  should  be  the  first  to  again  initiate 
transmission,  the  transmission  from  each  terminal  is  delayed  for  a random 
time  interval  and  then  retried.  Because  the  transmissions  are  terminated  as 
soon  as  a conflict  is  observed,  the  maxinxjm  possible  conflict  time  will  not 
exceed  the  longest  propagation  delay  in  the  system.  This  rapid  abort  on 
sensing  conflicting  transmissions  causes  only  a minimum  amount  of  data  to  be 
lost  due  to  data  collisions  on  the  line. 

If  a terminal  wishes  to  transmit  and  the  line  is  in  use  at  the  beginning 
of  the  scheduled  transmission,  the  transmission  will  be  delayed  until  the 
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Figure  5 


Typical  Listen-While-Talk  Bus  Architecture 


NO  or  WORDS  TRANSrtRRtO  PER  MESSAGE 


Figure  6 Effect  of  the  Number  of  Active  Terminals  on  Information  Transfer  Efficiency 


line  becomes  free.  At  that  point,  the  terminal  will  compete  for  the  line 
with  the  other  terminals  requesting  the  medium  according  to  the  process  just 
described. 

The  message  sequence  employed  in  this  investigation  was  taken  from  the 
Command  Controller  to  Remote  Terminal  transfer  response  sequence  described 
in  MIL-STD-1553A.  In  this  analysis,  the  value  of  the  interword  gap  (T)  has 
been  fixed  at  5 microseconds.  The  word  format  used  in  the  Listen-While-Talk 
model  is  the  standard  MIL-STD-1553A  word  format. 

The  effect  of  the  number  of  active  terminals  on  information  transfer 
efficiency  at  both  the  1 and  10  MH?  bus  operating  frequencies  is  shown 
in  Figure  6.  It  can  be  seen  that  the  fractional  information  capacity  of  the 
line  decreases  as  the  bus  frequency  increases.  This  phenomena  occurs  because 
of  the  increase  in  fractional  "no  signal"  capacity  created  by  the  fixed  value 
of  propagation  delay  regardless  of  the  bus  operating  frequency. 

COMPARISON  OF  BUS  ARBITRATION  TECHNIQUES 

In  order  to  allow  a comparison  of  data  transfer  performance  for  the 
various  bus  arbitration  techniques  covered  in  this  report,  a series  of 
assumptions  had  to  be  made.  These  assumptions  were  imposed  to  allow  the 
three  systems  to  operate  under  the  same  set  of  constraints.  For  the 
MIL-STD-1553A  conmand-response  protocol , only  the  results  of  operation  in  the 
terminal  to  terminal  mode  were  presented  in  the  comparison.  Although  remote 
terminal  to  controller  data  transfers  will  permit  higher  data  rate  transfer 
capability,  the  other  two  bus  protocol  systems  are  designed  to  transfer  infor- 
mation exclusively  in  the  terminal  to  terminal  mode.  A constraint  was  also 
imposed  on  the  GPMS  polled-contention  arbitration  technique  for  comparison 
purposes.  As  seen  from  the  previous  discussion  of  this  technique,  data 
transfer  performance  is  directly  related  to  the  number  of  terminal  responses 
received  as  a function  of  bus  offers  made.  To  determine  the  upper  bound  on 
data  transfer  performance,  it  is  assumed  that  a data  transfer  will  occur  for 
each  bus  offer.  Because  two  modes  of  bus  operation  are  possible  with  the 
polled-contention  configuration,  and  each  mode  has  a different  upper  bound 
on  data  transfer  performance  due  to  overhead  responses,  the  data  used  for 
comparison  is  an  average  of  the  performance  capabilities  of  the  two  modes. 

Both  the  polled-contention  and  pure  arbitration  techniques  can  increase  their 
effective  data  transfer  rates  by  use  of  active  redundant  cables.  Because 
this  technique  is  not  applicable  with  the  conmand-response  protocol,  the 
assumption  of  a single  line  transmission  system  has  been  made. 

A comparison  plot  of  the  various  techniques  considering  the  assumptions 
just  described  is  shown  in  Figure  7.  This  figure  describes  the  upper  bound 
on  data  transfer  rates  for  the  three  bus  arbitration  techniques  operating  at 
a one  megahertz  bus  rate.  From  this  diagram  it  can  be  seen  that  the  Listen- 
While-Talk  technique  demonstrates  the  best  data  transfer  rate  performance 
for  a 2 terminal  system,  but  as  the  number  of  active  terminals  increases, 
the  data  transfer  rate  decreases.  This  decrease,  as  previously  discussed, 
results  from  increased  overhead  created  by  collisions.  Figure  8 shows  a 


Figure  7 A comparison  of  the  Upper  Bound  on  Bit  Transfer  Rate  Performance  at  1 Megahertz 


Figure  8 A Conparison  of  the  Upper  Bound  on  Bit  Transfer  Rate  Performance  at  10  Megahertz 


plot  of  the  same  information  for  a bus  operating  at  10  megahertz.  It  can 
be  seen  from  this  figure,  that  with  only  2 active  terminals,  the  Listen- 
While-Talk  data  transfer  performance  is  less  than  the  polled-contention 
system,  and  performance  is  comparable  to  the  command- response  system  opera- 
ting in  the  remote  terminal  to  remote  terminal  mode.  In  both  Figures  7 and 
8 the  interword  and  intermessage  gap  was  fixed  at  5 microseconds.  As  shown 
earlier,  when  the  performance  results  of  the  individual  techniques  were 
examined,  the  command-response  and  polled-contention  techniques  are  sensitive 
to  interword  gap.  If  the  interword  gap  was  increased  from  5 to  10  micro- 
seconds, the  data  transfer  rates  for  the  polled-contention  and  command- 
response  curves  would  be  reduced  while  the  Listen-While-Talk  curves  would 
remain  unchanged.  It  should  be  noted  from  these  curves  that  data  transfer 
performance,  for  all  three  techniques,  drops  off  dramatically  as  the  number 
of  words  transferred  per  message  decreases.  This  has  become  a major  problem 
in  the  implementation  of  these  systems,  because  the  average  number  of  words 
transferred  per  message  in  an  avionics  application  tends  to  be  very  small. 

CONCLUSIONS 

From  the  results  of  this  investigation,  it  can  be  seen  that  for  all  the 
bus  techniques  studied,  the  upper  bound  on  data  transfer  performance  is  sensi- 
tive to  operating  frequency  and  the  number  of  words  transferred  per  message. 
For  the  MIL-STD-1553A  system,  the  effects  of  interword  and  intermessage  gap 
also  affected  information  transfer  performance.  In  the  GPMS  technique  the 
data  transfer  performance  was  sensitive  to  interword  and  intermessage  gap, 
and  the  number  of  active  terminals  in  the  network.  Under  conditions  where  a 
fixed  response  was  solicated  from  each  terminal  interrogated,  this  last 
parameter  has  no  effect  on  the  upper  bound  on  data  transfer  performance. 

The  number  of  terminals  in  the  network  responding  to  the  polling  controller 
does  affect  the  transfer  capability  between  terminals  for  long  message  ex- 
changes, i.e.,  greater  than  32  words.  The  Listen-While-Talk  technique, 
while  not  suffering  from  decreased  performance  due  to  interword  or  inter- 
message gap,  is  sensitive  to  the  bus  propagation  time  and  the  speed  of 
detecting  conflicting  transmissions.  Because  of  trie  lack  of  a control 
arbitrator  in  the  network,  the  probability  of  conflicts  increases  with  the 
number  of  active  terminals  in  the  system.  The  number  of  active  terminals 
in  the  network  is,  therefore,  a constraining  parameter  in  establishing  the 
upper  bound  on  transfer  performance  for  a Listen-While-Talk  System. 
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MULTIPLEXING  APPLICATIONS 

"CHAPTER  2" 
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Hughes  Aircraft  Company 
Microelectronic  Products  Division 
Newport  Beach,  California 


This  paper  is  an  update  of  one  given  at  the  1st  Multiplex  Data  Bus 
Conference,  in  November  of  1976.  It  describes  the  LSI/Hybridized 
MIL- STD-1553  Remote  Terminal  in  development  at  the  Microelectronic 
Systems  Division  of  Hughes  Aircraft  Conpany.  The  design  concept  is 
reviewed  along  with  those  changes  necessary  to  incorproate  the  1553B 
requirements.  The  paper  discusses  several  interfaces  and  program- 
ming functions  which  adapt  the  Remote  Terminal  to  various  MIL- STD-1553 
applications,  e.g.,  F-16,  F-18  aircraft  and  1553B  MUX  systems. 
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INTRODUCTION 


The  Hughes  MIL-STD-1553  Remote  Terminal  (RT)  design  concept 
evolved  from  a problem  faced  by  n»ny  large  companies  that  are  develop- 
ing avionics  hardware.  If  the  company  has  mar\y  divisions,  each  pro- 
ducing a variety  of  avionics  and  missiles  systems,  each  division  will 
in  certain  common  hardware  areas  tend  to  re-invent  the  wheel.  This  is 
true  of  multiplex  hardware  required  of  these  avionic  and  missile 
systems.  This  problem  is  magnified  when  a particular  avionics  system 
is  required  to  operate  on  different  type  aircraft  or  weapon  systems 
that  have  different  type  MIL-STD-1553  systems,  e.g.,  F-16  (1553  Basic), 

F-18  (1553A),  new  vehicles  (1553B). 

To  solve  the  above  stated  problem,  the  Microelectronic  Systems 
Division  of  Hughes  accepted  the  task  to  develop  LSI  and  hybrid  devices 
that  can  be  assembled  into  Remote  Terminals  which  then  can  be  modularized 
and  programmed  to  meet  the  various  1553  applications.  A stuc|y  was 
conducted  to  determine  the  feasibility  and  economics  of  developing  a 
universal  RT  design  to  achieve  standardization  and  interchangeability 
of  hardware.  From  the  study  the  following  listed  design  goals  were 
established,  against  which  each  facet  and  parameter  of  the  design  was 
evaluated: 

1.  The  RT  hardware  (Front  End)  must  be  adaptable  to  both  single 
and  dual  bus  systems. 

Z.  Redundancy  in  the  RT  (between  bus  and  subsystem)  incorporated 
to  the  maximum  depth  possible.  In  a dual  bus  RT  no  single 
failure  will  disable  the  communication  function  of  the  terminal. 

3.  A standardized  RT  to  subsystem  interface  establi shed  which 
will  work  with  all  type  air  vehicle  subsystems  without  rede- 
sign of  the  RT  Front  End. 

4.  The  RT  must  be  programmable  to  work  with  existing  1553  MUX 
systems  and  with  new  1553B  applications. 

5.  The  RT  must  be  self  supporting  in  that  it  requires  no  support 
from  its  host  subsystem  other  than  prime  power  forms. 

6.  The  RT  elements  must  be  productized  in  LSI  and  hybrid  technolo- 
gy for  optimum  adaptation  (size  and  power)  to  all  subsystem 
black  boxes. 

7.  The  RT  and  its  functions  must  be  simplified  to  the  fullest 
extent. 

A.  MUX  bus  synchronous  word  exchange  with  the  subsystem, 
i.e. , no  message  block  memory. 

B.  Standard  (intermediate)  interface  to  work  with  all  subsystems. 
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These  design  goals  have  been  met  in  the  development  of  the  RT  and 
its  elements.  The  following  material  describes  and  discusses  the 
basic  design  concept  of  the  RT  approach. 

DESIGN  CONCEPT 

The  Hughes  Remote  Terminal  (RT)  can  best  be  described  by  reference 
to  Figure  1 and  2 accompanied  with  description  of  the  functional 
interfaces.  Figure  1 depicts  a representative  dual  bus  RT  showing  the 
five  interfaces  involved  in  the  operation  of  the  RT.  Figure  2 shows  a 
singular  Front  End  Module  (FEM)  which  is  the  prime  element  of  the 
RT. 

1.  Remote  Terminal  To  Mux  Bus  Interface 

This  interface,  for  each  RT  application,  is  defined  by  the  various 
vehicle  MUX  specifications  (i.e. , 1553)  and  therefore  is  not  discussed 
here. 

2.  Remote  Terminal  to  Subsystem  Interface 

This  interface  is,  and  will  be  for  sometime  to  come,  different 
with  each  application  of  a RT  to  different  type  subsystems.  Hughes 
design  concept  does  sinplify  the  implementation  of  this  interface  by 
establishing  an  Intermediate  Subsystem  Interface  between  the  RT  Front 
End  and  the  host  subsystem  wherein  all  necessary  functions  are  provided 
for  adaptation  to  the  subsystem  by  a minimum  of  additional  circuitry. 

This  approach  eliminates  the  differences  in  subsystem  functions  from 
reflecting  back  into  the  RT  past  the  intermediate  interface. 

3.  Intermediate  Subsystem  Interface  (Standard) 

In  the  Hughes  design  this  interface  is  most  critical  since  it 
affects  standardization  in  usage  of  the  RT.  At  this  interface  (See 
Figure  3)  all  known  and  necessary  functions  are  present  to  enable  any 
Avionics  type  subsystem  to  be  serviced  via  bi-directional  data  transfer 
or  an  Electrical/Airframe  type  RT  to  control  the  programming  of 
its  I/O  signal  conditioning  circuitry. 

This  interface,  with  the  Subsystem  Interface  Logic  (SSIL)  cirucitry, 
buffers  the  ever  changing  function,  required  of  the  different  host 
subsystems,  from  advancing  back  into  the  RT  causing  redesign  of  the 
FEM.  The  interface  functions,  in  the  majority  of  application  (dual 
bus),  will  be  harc^ire  OR-ed  from  the  two  FEM's  to  the  appropriate 
SSIL.  The  interface  functions  are  shown  in  Figure  3.  An  example  is 
given  of  a SSIL  and  those  intermediate  interface  functions  used  to 
provide  bi-directional  data  exchange  with  an  avionics  communication 
subsystem  (via  DMA)  which  incorporates  a microprocessor.  Other  inter- 
face functions  labeled  'Provisional'  are  primarily  used  for  implement- 
ing a RT  which  is  used  to  control  the  processing  of  EMUX  type  signals, 
e.g,  analog,  discrete  and  synchro.  Of  particular  interest  are  the 
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Figure  ?.  Representative  Front  End  Module  (Single  Bus) 
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seven  status  lines  made  available  at  the  interface  which  can  be  used 
depending  upon  the  MUX  status  word  and  format  required,  to  configure 
the  status  word  bits  for  the  particular  1553  type  MUX  system  being 
employed  on  the  vehicle. 

4.  Cross-Tie  Interface 

A single  bus  system  application  can  be  serviced  by  one  Front  End 
Module  (FEM).  In  a dual  bus  application  Hughes  concept  necessitates 
the  use  of  two  FEM's.  With  this  approach  operational  redundancy  and  RT 
sectional  control  is  made  available  at  the  subsystem  interface. 

Carrying  redundancy  to  this  depth  requires  that  the  two  FEM's  have  a 
means  of  cross-tie  control  to  affect  the  inhibit  or  enabling  of  one 
another.  Two  critical  inter-tie  functions,  'reset'  and  'valid  command 
received'  are  fail  safe,  that  is,  no  single  point  failure  can  knock  out 
both  FEM's,  since  the  FEM's  using  the  functions  are  looking  for  an  edge 
(edge  detection)  rather  than  a signal  level  (high  or  low).  Other 
signals  consist  of  transmit  disable,  and  bus  shutdown  functions. 

5.  Programming  Interface 

Table  1 lists  those  functions  provided  at  the  subject  interface. 
These  functions  are  made  available  on  pins  either  at  the  FEM's  or 
the  Printed  Circuit  Board  on  which  the  FEM(s)are  mounted.  Actual 
plysical  programming  is  accomplished  by  connecting  RT  signal  ground 
to  the  desired  programming  pin  (Logic  0)or  leaving  the  pin  non-connected 
(Logic  1).  This  interface  (via  pin  programming)  allows  the  standard 
FEM's  to  be  programmed  for  that  particular  1553  format  and  protocol 
required  of  the  vehicles  MUX  system.  The  interface  presently  allows 
programming  for  F-16,  F-18  MUX  Specifications  and  MIL-STD-1553B  Standard 
applications. 


Table  1.  Programming  Interface  Functions 

0 Bus  Application  (Protocol)  Select  (2  pins) 
0 Broadcast  Disable  (1  pin) 

0 Mode  Control  Select  (1  pin) 

0 RT-to-RT  Response  Time  Select  (1  pin) 

0 Up/Oown  Word  Count  Select  (1  pin) 

0 RT  Address  (5  pins) 

0 DMA  Address  Select  (5  pins) 
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To  explain  the  programmable  functions  one  must  first  understand 
the  internal  functions  performed  by  the  Controller  (LSI  #2)  that 
receives  the  programming  inputs.  The  Controller  incorporates  a 30 
line  micro-programmed  control  bus,  and  performs  the  following  functions: 


0 Message  Validation 
0 Message  Decoding 

Address  Decodi ng 
Transmit/Receive  Decoding 
Subaddress/Mode  Control  Decoding 
Mode  Code  Decoding 
Word  Count  Decodi ng 
0 Status  and  Data  Encoding 
Sync  Pattern  Generation 
Status  Word  Generation  and  Formatting 
Manchester  Encoding 
Subsystem  Addressing 
Fail-Safe  Time-Out 
Redundancy  Interface  Control 
Data  Word  Transfer  Control 
Status  Response  Control 

These  programmable  functions  are  inplmented  in  the  design  of  the 
Controller  (LSI  #2),  a discussion  of  each  follows. 

0 Bus  Application  (Protocol)  Select  - Two  binary  coded  pin  inputs 
are  provided  for  selecting  the  protocol  that  is  used  for  one  of 
the  three  applications,  F-16,  F-18  and  1553B.  Differences  in 
protocol  occur  in  the  area  of  status  bit  definition  (see  Table 
2),  resetting  of  status  bits, data  handling  under  error  condi- 
tions, and  mode  code  assignments  (see  Table  3). 


0 Broadcast  Disable  - Provided  for  1553B  applications,  one  input 
allows  the  broadcast  function  of  the  terminal  to  be  completely 
disabled,  if  desired. 

0 Mode  Control  Select  - One  input  is  provided  to  define  the  mode 
control  field  either  as  OOOUO  or  11111  for  terminal  application. 

0 RT-to-RT  Response  Time  Select  - One  input  selects  the  maximum 
time  interval  (either  7.5  us  or  12.5  us)  the  receiving  RT  will 
wait  for  a status  response  from  the  transmitting  RT  once  a 
RT  to  RT  command  sequence  has  been  detected.  This  function  is 
incorporated  to  facilitate  the  difference  in  RT  status  response 
time  between  the  various  MUX  specifications. 


0 Up/Down  Word  Count  Select  - One  input  determines  if  the  message 
word  count  field  controller  output  to  the  subsystem  should  be 
incremented  or  decremented  by  one  for  each  data  word  received/ 
transmitted.  DMA  addressing  of  the  host  subsystem  memory  may 
use  an  incremented  count,  while  other  applications  use  a 
decremented  count. 
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0 RT  Address  - Five  inputs  are  provided  for  the  selection  of  the 
unique  RT  address. 

0 DMA  Address  Select  - Five  inputs  are  provided  for  block  message 
addressing  of  the  host  subsystem  memory  when  DMA  is  used. 


Table  2 . Status 

Bit  Allocation 

Bit 

No.  F-16 

F-18 

1553B 

9 

Parity  Error 

Msg.  Error 

Msg.  Error 

10 

Inst. 

ND 

Inst. 

11 

Msg.  Error 

ND 

Serv.  Req. 

12 

NA 

ND 

ND 

13 

NA 

ND 

NO 

14 

NA 

ND 

ND 

15 

Broadcast  CMD  RCV 

ND 

Broadcast  CM)  RCV 

16 

Mode  CM)  RCV 

ND 

Busy 

17 

Bus  B Shutdown 

ND 

SS  Flag 

18 

Bus  A Shutdown 

ND 

Dyn  Bus  Control 

19 

RT  Status 

RT  Flag 

RT  Flag 

ND 

- Not  Defined  NA 

- Not  Applicable 

Table  3. 

Mode  Command 

Allocation 

CMD 

F-lb 

F-18 

1553B 

XMT  Status 

X 

ND 

X 

XMT'R  Disable 

NR 

ND 

X 

XMT'R  Enable 

NR 

ND 

X 

Reset  RT 

NR 

ND 

X 

Synchronize 

NR 

ND 

X 

Reset  Timer 

X 

ND 

NR 

Inhibit  T/F  Flag 

NR 

ND 

X 

Override  T/F  Flag 

NR 

NO 

X 

ND  - Not  Defined  NR  - Not  Required 
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ADAPTABILITY  BY  COMPONENT  REVISION 

One  of  the  most  difficult  requirements  in  the  design  of  a stan- 
dardized RT  applies  to  the  generation  of  the  RT  transmitted  waveforms 
required  of  different  MUX  specifications,  e.g.,  sinewave  type  with 
limited  harmonic  content-vs-trapezoi dal  waves.  Figures  4a,  b,  c 
depict  the  RT  transmitted  waveform  limit  envelopes  for  the  F-18, 

F-16  aircraft  and  155JB  MUX  system  applications.  Figure  5a  shows  the 
current  Hughes  RT  baseline  waveform  designed  toward  the  F-18 
application.  Figure  6 is  a graph  showing  the  variation  in  harmonic 
content  between  the  MDC  A3818  Spec,  and  the  Hughes  baseline.  The  graph 
shows  that  the  Hughes  waveform  adheres  to  the  harmonic  content  suppres- 
sion of  MDC  A3818  except  for  a 3 dB  variation  at  3 MHz.  Hughes  studies 
and  test  indicate  the  Hughes  baseline  waveform  is  a optimized  trade-off 
between  harmonic  suppression  per  MDC  A3818  and  circuit  complexity 
required  for  practical  implementation  of  a 1553  transmitter  in  a 
hybrid  package.  For  F-16  and  1553B  MUX  system  applications  which 
require  trapezoidal  transmitted  waveforms  (see  Figures  4b  and  4c), 
the  removal  of  six  discrete  components  from  the  Front  End  Hybrid 
(transmitter  section)  produces  the  waveform  shown  in  Figure  5b.  The 
Hughes  square  wave  option  waveform  falls  within  both  the  F-lb  and  the 
1553B  envelope  limits. 


4a 


4b 


4C 

Figure  4(a,  b,  C).  Transmitted  Waveform  Limit  Envelopes 
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Figure  5 (A,  B).  Transmitter  Waveforms  (Hughes  RT  Concept) 
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Figure  6.  Conparison  of  Transmitted  Waveform  Harmonic  Content 
(MOC  A3828  & Hughes  Baseline) 
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GENERAL  RT  DESIGN  PARAMETERS 

0 Radiation  Level  - RT  circuit  elements  are  designed  to  radiation 
levels  of  10^  rads  total  dose  and  108  rad/sec.  transient. 

0 Environmental  Level  - RT  circuits  designed  to  meet  requirements 
of  MIL-E-5400  Class  II. 

0 Size/Volume/Power  of  RT  Elements 

Front  End  Hybrid 

Size:  2.4"  x 1.6" 

No.  of  pins:  90 

Power  Dissipation:  4 watts 
Circuit  Technology: 

TX/RX  - Discrete  devices 
Sync/Data  Detector  LSI  - SOS  CMOS 
Controller  LSI  - Standard  CMOS 

Subsystem  Interface  Hybrid 

Size:  1.9"  x 1.6" 

No.  of  pins:  72 

Power  Dissipation:  5 watts 
Circuit  Technology: 

Subsystem  Interface  Logic  - 35  Schottky  TTL,  SSI  and  MSI  devices 


Dual  Channel  RT  with  Subsystem  Interface  Logic 

Size:  5.6"  x 5.8"  Printed  Circuit  Board 

Power  Dissipation:  13.6  watts  {20:1  transmit  duty  cycle) 
Power  Forms:  +5  Vdc 

+12  Vdc 


DUAL  CHANNEL  I553A  INTERFACE 


Robert  Hoffman 
Applied  Technology,  Division 
of  Itek  Corporation 
Sunnyvale,  California  94086 


ABSTRACT 

General  design  tradeoffs  for  a I553A  interface  are  reviewed  and  a set  of  design  goals 
identified.  A description  of  one  design  approach  is  given.  The  description  covers  signal 
level  conversion,  decoding,  control,  and  subsystem  to  interface  communications. 

BASIC  CONSIDERATIONS 


The  design  of  a I553A  interface  requires  some  functions  that  are  common  to  every 
system.  First,  some  sort  of  circuit  is  needed  to  receive  the  high  level  differential  signals 
from  the  bus  and  transform  them  to  normal  system  levels.  Circuitry  is  also  required  to 
perform  the  reverse  function,  driving  signals  from  the  system  to  the  bus.  These  two 
functions  are  basically  analog.  A method  of  retrieving  the  timing  information  from  the 
incoming  signal  is  needed.  This  function  can  be  accomplished  in  either  an  analog  or  c 
digital  fashion.  Decoder  and  encoder  are  needed  to  perform  the  conversion  of  Manchester 
serial  data  to  parallel  TTL  NRZ  data  and  the  reverse. 

At  this  point,  host  system  requirements  vary.  The  two  remaining  interface  functions 
are  control  and  data  exchange  with  the  host  system.  I553A  requires  a system  to  examine 
incoming  bus  commands  and  take  different  actions  dependent  on  the  data  therein.  This 
function  can  be  built  into  the  interface,  or  handled  by  the  host  system  directly  (Fig.  I). 
Thelatteris  attractive  for  saving  design  time  and  hardware,  but  is  much  more  difficult 
than  it  appears.  Assuming  that  the  host  system  has  a computei , the  interface  would 
normally  provide  an  interrupt  to  Indicate  that  data  has  been  received  and  service  is 
needed.  The  most  common  point  for  this  to  occur  is  after  a remote  terminal  has  received 
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and  decoded  an  incoming  command  word.  It  is  probable  that  the  decoder  would  not 
initiate  the  interrupt  until  the  word  is  complete  and  parity  has  been  checked.  The  host 
CPU  now  has  a maximum  of  five  microseconds  to  begin  a response  on  the  bus,  if  that  is 
the  correct  action.  First,  the  computer  must  reach  a point  at  which  it  can  accept 
interrupts.  This  in  itself  may  take  more  than  the  time  allowed,  but  let  us  assume  that 
the  interrupt  is  accepted  and  recognized  in  a negligible  amount  of  time.  The  CPU  must 
now  store  its  operating  context  and  retrieve  its  interface  context.  Again,  this  can  be 
an  extensive  procedure,  but  we  will  assume  only  a minimal  time  loss.  Now  the  CPU 
must  fetch  the  word  from  the  interface  and  evaluate  the  address  field  to  see  if  the  command 
pertains  to  this  system.  If  the  answer  is  yes,  the  command  word  must  be  examined  further 
to  evaluate  subaddress,  mode,  and  receive/transmit  fields.  Now  the  CPU  knows  what 
action  to  take  and  can  begin  a response.  Some  further  time  is  required  to  transform  the 
response  initiate  instruction  from  the  CPU  into  a waveform  properly  coded  on  the  bus.  To 
accomplish  all  of  this  in  five  microseconds  or  less,  as  measured  at  the  bus,  is  extremely  dif- 
ficult for  most  operating  systems.  As  the  process  must  be  followed  through  address 
identification  for  every  command  word  on  the  bus,  the  host  system  CPU  must  be  able  to 
spend  an  appreciable  amount  of  time  in  interface  servicing. 

In  many  cases  these  two  requirements,  that  of  response  time  and  that  of  operating 
time,  are  enough  to  rule  out  direct  interface  control  by  the  host  system.  If  the  control 
function  is  built  into  the  interface,  a second  problem  arises.  The  interface  can  service 
the  bus  and  accept  and  store  incoming  data,  but  it  must  also  make  this  data  available  to 
its  host  system.  The  choice  of  data  transfer  method  should  be  tailored  to  the  host  system's 
needs.  I/O  or  DMA  modes  may  be  acceptable  if  they  do  not  require  excessive  CPU  time. 

GOALS 


With  these  problems  in  mind,  some  goals  were  set  for  the  serial  interface  unit,  or  SlU. 
First,  the  interface  should  be  versatile  enough  to  be  readily  adapted  to  other  systems.  The 
design  effort  was  estimated  to  be  significant  and  a redesign  task  for  every  new  I553A 
application  should  be  avoided.  This  required  the  interface  to  be  self-contained,  requiring 
only  power,  clocks  and  data  interface  from  its  host  system.  This  in  turn  implies  an 
independent  interface  able  to  handle  completely  the  protocol  of  the  bus.  The  space 
allotted  for  the  interface  was  one  6x7  card,  equivalent  to  105  16  pin  I.C.  spaces.  It 
was  required  that  the  SlU  contain  two  totally  independent  bus  interfaces,  and  that  each 
operated  under  software  control  by  the  host  system. 

THE  RECEIVER 

Meeting  these  goals  proved  to  be  an  Interesting  design  task.  The  description  of  the 
design  starts  with  the  most  rigidly  defined  point,  the  bus  itself.  Two  identical  bus 
connections,  consisting  of  the  specified  isolation  resistors  and  the  transformer  are  on  the 
card.  Each  channel  transformer  drives  a hybridized  analog  transceiver  circuit.  The  hybrid 
filters  out  high  frequency  noise  on  the  input,  amplifies  the  waveform,  and  applies  it  to  two 
comparators.  One  comparator  is  set  to  fire  when  the  differential  input  voltage  exceeds  a 
positive  threshold  level.  The  other  fires  when  the  waveform  is  more  negative  than  a 


548 


negative  threshold  level.  Both  thresholds  con  be  adjusted  externally  to  the  hybrid.  When 
a comparator  is  active,  its  output  is  a TTL  logic  one.  These  two  logic  outputs  of  the  hybrid, 
one  denoting  a positive  differential  voltage  on  the  bus,  the  other  a negative  bus  voltage 
(Fig.  2)  are  passed  on  to  a digital  sampling  circuit. 

Both  the  timing  and  data  information  in  the  bus  waveform  are  contained  in  the 
direction  and  time  between  zero  crossings,  but  due  to  noise  and  other  problems,  these 
points  may  be  difficult  to  detect.  It  may  be  noted,  however,  that  the  time  between  the 
waveform  exceeding  a positive  threshold  and  exceeding  the  following  negative  threshold 
equals  the  time  between  zero  crossing  for  symetrical  waveforms  (Fig.  2).  Therefore,  the 
rising  edges  of  the  two  hybrid  outputs  provide  a shifted  but  real  zero  crossing  indication. 
These  outputs  are  then  sampled  by  a 16  MHZ  clock,  looking  first  for  one  rising  edge,  then 
the  other.  Each  detected  rising  edge  loads  the  output  of  a 16  MHZ  pulse  width  counter 
into  a FIFO  and  clears  and  restarts  the  counter.  The  polarity  of  the  measured  pulse  is  also 
loaded  into  the  FIFO.  This  sampling  approach  avoids  the  task  of  reconstructing  the  bus 
timing  and  provides  the  first  step  in  synchronizing  the  bus  waveform  to  system  timing.  The 
FIFO  accomplishes  the  second  step  of  synchronization  by  providing  for  a separate  input  and 
output  clock.  It  also  provides  a "rubber  band"  data  storage,  allowing  the  output  circuit 
to  ignore  received  pulses  for  a few  cycles  without  losing  data.  Each  channel  has  its  own 
pulse  measurement  circuit  and  FIFO. 

THE  DECODER 


The  decoder  function  of  the  SlU  is  implemented  in  the  form  of  a state  machine.  A 
flowchart  can  be  drawn  for  the  decisions  required  to  decode  the  stream  of  pulse  width  and 
polarity  information  coming  from  the  bus  through  the  digital  receiver.  Each  decision  Is 
based  on  all  previous  decisions  within  the  current  word  and  the  current  pulse  width  data. 

The  flowchart  can  be  directly  converted  to  hardware  in  the  form  of  a state  machi  ne  (Fig.  3). 
As  each  digital  receiver  will  record  pulses  at  a maximum  rate  of  less  thon  two  MHZ,  a 
state  machine  running  at  a 4 MHZ  rate  can  handle  both  receivers.  Keeping  track  of  the  two 
channels  merely  requires  two  state  latches  olternately  active.  On  the  SlU,  a two  MHZ 
clock  provides  channel  control.  When  the  clock  is  low,  channel  zero  is  being  decoded; 
when  the  clock  is  high,  channel  one  is  being  decoded.  The  state  machine  must  keep  track 
of  Its  place  within  an  incoming  word,  so  it  automatically  provides  a bit  count  function. 

It  also  easily  accepts  the  job  of  tracking  and  checking  parity.  Tlie  state  machine  provides 
serial  NRZ  data  as  an  output,  and  flags  to  indicate  its  status  to  a control  processor.  The 
data  is  accumulated  in  a buffer  file  register.  The  buffer  file  is  an  eight  bit  by  16  word  two 
port  RAM,  where  one  port  is  serial  and  is  dedicated  to  the  decoder  and  the  other  is  parallel 
and  dedicated  to  the  control  processor.  The  decoder  status  flag  outputs  are  written  into  a 
status  flag  register  on  command  of  the  decoder.  The  write  to  the  status  flag  register  is  used 
as  a channel  identified  decoder  interrupt  to  the  control  processor.  The  status  flag  register 
contents  are  read  by  the  control  processor.  Interrupts  are  sent  at  the  end  of  each  byte  of 
the  word  being  decoded.  This  allows  the  processor  to  operate  in  a look  ahead  rTX>de,  re- 
lieving the  more  critical  timing  cycles.  A control  flag  register  is  loaded  by  the  control 
processor  with  control  flag  information  identified  by  channel.  The  decoder  state  machine 
can  select  to  read  these  flags  instead  of  FIFO  outputs.  When  the  decoder  selects  the  flogs 


as  inputs,  one  bit  of  the  serial  output  of  the  buffer  file  data  is  also  available. 

During  the  transmit  function,  when  the  SID  is  driving  data  onto  the  bus,  the  data 
to  be  transmitted  is  taken  from  the  buffer  file  by  the  decoder  and  sent  in  TTL  Manchester 
format  directly  to  the  transceiver  hybrid.  Transmit  control  signals  are  also  provided  by 
the  decoder  to  the  hybrid.  The  hybrid  performs  the  functions  of  level  translation, 
amplification,  and  waveform  smoothing  and  drives  the  bus  transformer. 

THE  CONTROL  PROCESSOR 


The  Control  Processor  performs  the  message  control  function  for  the  SlU.  An  eight 
BIT  architecture  was  chosen  as  the  optimum  space  to  speed  tradeoff.  A 16  BIT  wide  path 
would  have  token  too  much  space  and  a 4 BIT  wide  path  could  not  have  run  fast  enough  to 
service  both  channels  for  two  simultaneously  arriving  16  BIT  words.  The  Processor  uses 
2901's  as  ALU  and  register  storage  with  16  additional  registers  provided  externally.  A two 
bus  architecture  is  used  to  allow  the  8 BIT  processor  to  execute  a 16  BIT  memory  interface 
operation  in  one  cycle  (Fig.  4).  The  2901 's  and  the  buffer  file  input  data  from  the  upper 
bus  and  output  data  to  the  lower  bus.  The  external  registers  input  data  from  the  lower  bus 
and  output  to  the  upper  bus.  The  memory  interface  registers,  the  address  register,  data 
in  register,  and  data  out  register,  load  or  drive  upper  BYTE  data  from  or  to  the  upper  bus 
and  lower  BYTE  data  from  or  to  the  lower  bus.  This  allows  the  Processor  to  load  the  upper 
BYTE  of  a memory  reference  word  from  the  external  registers  and  the  lower  BYTE  from  the 
2901  registers  to  the  memory  interface  registers  in  one  micro  instruction.  The  upper  bus 
also  can  drive  data  to  the  microcode  address  registers  or  be  driven  by  the  emit  field  of 
microcode.  The  first  allows  the  Processor  to  directly  use  memory  data  as  a microcode  ad- 
dress and  the  second  allows  data  such  as  masks  to  be  stored  in  microcode. 

The  microcode  address  is  generated  from  one  of  three  sources  (Fig.  5).  A micro- 
sequencer provides  both  a microprogram  counter  and  a branch  register.  The  branch 
register  is  loaded  either  from  the  microcode  data  field  or  the  upper  bus.  Unconditional 
branch  control  is  from  microcode  and  conditional  branching  uses  the  zero  and  negative 
flags  from  the  2901 's.  The  third  microcode  address  source  is  the  interrupt  branch  register, 
or  IBR.  The  register  drives  the  bus  only  when  interrupts  are  being  polled.  It  is  an  8 BIT 
four  word  RAM  with  the  same  data  Inputs  as  the  microsequencer . The  IBR  is  addressed  by 
the  highest  priority  interrupt  present.  The  contents  of  the  register  are  loaded  at  the  end 
of  an  interrupt  service  with  the  microcode  address  to  be  executed  first  when  that  same 
interrupt  is  serviced  next.  With  all  processor  registers  dedicated,  the  interrupt  branch 
system  allows  the  Processor  to  step  from  one  Interrupt  service  routine  directly  Into  any 
other  interrupt  service  routine  in  only  one  cycle.  The  reason  for  this  interrupt  driven 
organization  is  the  unpredlctobility  of  the  processor's  sequential  operations.  Two  interrupts 
are  from  the  decoder,  one  for  each  channel . The  third  interrupt  is  from  the  host  CPU,  and 
the  fourth  is  available  to  the  host  system  for  general  use.  The  four  Interrupts  are  prioritized 
in  two  groups.  Group  one  contains  the  interrupts  from  the  decoder  and  has  the  highest 
priority.  Within  the  group,  the  priority  is  not  rigid.  Channel  zero  is  given  nominal 
precedence,  but  with  both  channel  zero  and  one  interrupts  pending,  the  channel  currently 
being  serviced  will  assume  a lower  priority.  Group  two  interrupts  are  from  the  host  system 


and  have  fhe  same  floafing  priorify  within  the  group. 
FIRMWARE 


The  interrupt  driven  processor  operation  combined  with  the  timing  limitations  make 
the  microcode  task  difficult.  The  decoder  operates  over  a word,  sending  two  interrupts  to 
the  Processor  for  each  word  on  each  channel . The  Processor  operates  on  a message  basis, 
but  must  service  only  a byte  of  a message  at  a time.  The  microcode  instruction  essentially 
covers  the  full  message  length,  but  must  be  driven  from  one  sub-instruction,  micro-routine, 
to  the  next  by  decoder  interrupts.  During  a given  period,  all  interrupt  levels  may  have 
instructions  in  progress.  The  Processor  will  perform  one  micro-routine  in  a given  interrupt 
level,  and  then  step  to  the  next  micro-routine  for  the  highest  level  interrupt  present.  The 
interrupt  prioritization  guarantees  that  the  Processor  will  accept  for  service  an  interrupt  on 
any  level  before  the  next  interrupt  on  that  level  will  occur.  If  each  channel  receives  a 
command  word  at  the  same  time,  both  will  send  decoder  interrupts  to  the  Control  Processor 
at  the  end  of  the  first  BYTE  received.  The  Processor  must  accept  the  highest  priority  inter- 
rupt, process  the  flags  and  dota  from  the  decoder,  make  any  decisions  necessary,  and  load 
control  flogs  for  the  decoder.  It  must  then  do  the  same  for  the  second  channel.  As  the 
decoder  will  examine  the  control  flags  for  each  channel  and  send  two  new  channel  interrupts 
to  the  Processor  at  the  end  of  the  second  BYTE  received  on  each  channel,  the  Processor 
must  be  able  to  service  both  of  the  original  interrupts  in  no  more  than  ten  microseconds,  or 
each  in  less  than  five.  At  a 250  ns  cycle  time,  this  allows  only  twenty  or  less  micro 
instructions  to  service  a BYTE  of  data.  If  a memory  reference  is  required,  no  more  than 
twelve  micro  instructions  are  allowed.  These  timing  requirements  highlight  the  importance 
of  the  rapid  interrupt  service  context  switching. 

SOFTWARE 

The  basic  space  limitation  of  the  SID  makes  it  impractical  to  hold  all  interface 
operating  parameters  in  the  interface  itself.  Such  data  as  sub-address  data  buffer  pointers 
and  mode  command  response  words  are  kept  in  the  host  system  main  memory.  The  interface 
has  its  own  port  into  one  section  of  this  memory,  allowing  immediate  access  to  flag  words, 
pointers,  and  multiple  data  buffers.  One  memory  location  is  designated  as  an  SlU  control 
word.  The  host  CPU  writes  an  SlU  control  word  to  this  location  and  then  sends  an  interrupt 
to  the  SlU.  When  the  SlU  services  this  interrupt,  it  reads  this  memory  location  and  then 
zeros  it  to  inform  the  host  CPU  that  the  command  has  been  acknowledged.  On  power  up, 
the  host  CPU  loads  tables  into  memory  that  provide  pointers  for  all  active  receive  and 
transmit  sub  addresses  and  all  mode  commands.  When  the  SlU  receives  a command  word 
from  the  bus,  the  Control  Processor  uses  the  transmit/receive  bit  and  the  sub  address  field 
as  a vector  into  this  table.  The  content  of  the  word  accessed  is  the  memory  address  of  the 
correct  transmit  or  receive  data  buffer.  If  the  sub  address  field  of  the  command  word  is 
all  zeros,  the  Control  Processor  uses  the  word  count  field  as  the  vector  into  the  mode  com- 
mand table.  As  these  vector  tables  are  in  the  host  CPU's  main  memory,  it  can  change  the 
data  in  the  tables  at  any  time.  This  allows  the  CPU  to  accumulate  data  for  transmission 
in  a working  buffer,  and  then  simply  enter  that  buffer's  address  in  the  vector  table  to  make 
the  data  available  to  the  SlU.  For  incoming  data,  the  CPU  puts  the  address  of  an  empty 
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buffer  in  rhe  vector  table.  When  the  CPU  receives  an  interrupt  from  the  SlU,  it  examines 
the  locatioii  in  memory  that  contains  the  SlU  status  word.  This  directs  the  CPU  to  the 
buffer  that  is  now  full.  The  CPU  can  now  change  the  vector  table  pointer  to  another 
empty  buffer  and  process  the  received  data  without  moving  it  and  with  no  danger  of  it 
^ing  overwritten.  This  approach  to  interface-to-CPU  data  handling  requires  a minimum  of 
CPU  time  ar>d  programming. 

SUMMARY 

The  Serial  hterface  Unit  contains  two  totally  independent  I553A  interfaces  on  one 
6x7  card.  Each  interface  may  be  microcoded  to  be  either  a remote  terminal  or  a control 
teimlnal.  They  may  operate  separately  or  as  a redundant  pair.  The  algorithmic  decoder 
« implemented  In  standard  MSI  lotches  and  PROMS.  These  PROMS  may  be  re-programmed 
to  hardle  variations  or  changes  in  bus  protocol . Its  small  size,  standard  components  and 
flexibility  make  it  an  attractive  alternative  to  LSI  implementations.  The  interface  control 
processor  handles  the  complete  bus  interface  function.  The  host  CPU  merely  receives 
notification  of  a completed  message  from  a remote  terminal.  For  a control  terminal,  the 
host  CPI J sends  one  interrupt  to  initiate  a message  and  receives  an  interrupt  upon  completion 
of  the  message.  Host  system  communications  with  the  interface  are  through  main  memory, 
avoiding  more  time  consuming  I/O  operations.  As  no  data  shifting  is  needed.  Interface 
support  software  requires  only  small  amounts  of  code  and  CPU  time,  ft  is  possible  for  the 
control  processor  to  be  programmed  to  perform  auxiliary  tasks  in  support  of  the  host  CPU. 

It  may  also  be  programmed  to  be  a stand-alone  unit.  The  SlU  requires  only  basic  inputs 
from  a host  system  and  is  therefore  easily  appended  to  any  existing  or  future  system. 
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ABSTRACT 


This  paper  describes  the  architecture,  features,  and  operation  of  one 
family  in  a spectrum  of  Flexible  Multiplex  Terminal  Interfaces  (FMTI) 
available  at  SCI.  This  family  of  Bus  Control  Units  (BCU)  is  a set  of  multi- 
function bus  interfaces,  each  tailored  for  operation  with  a specific  host 
processor.  The  BCU  design  provides  a data  bus  interface  unit  with  direct 
memory  access,  programmable  interrupts,  built-in-test,  and  programmab-e 
operating  mode. 

A BCU  can  operate  as  a MIL-STD- 1553A  bus  controller  or  remote 
terminal.  Additional  operating  modes  are  bus  monitor  and  bus  analyzer,  as 
defined  elsewhere  in  this  paper.  Another  available  feature  is  simulation  of 
all  RT's  ona  given  bus  (up  to  32).  It  is  not  implemented  on  all  BCU's  becai.se 
of  space  constraints. 

The  BCU  design  employs  a bipolar  bit-slice  microprocessor  for  supf. -i: 
flexibility.  The  standard  operating  modes  occupy  approximately  800  words  &i 
microcode,  while  the  architecture  allows  utilization  of  up  to  4096  words. 

All  operational  features  are  firmware  controllable.  As  a result,  the  upgrade 
to  MIL-STD-1553B  can  be  accomplished  by  a straight-forward  microcode 
update.  Firmware  commonality  among  BCU  family  members  is  greater  thar 
90%,  with  common  source  code  for  all  bus  processing  modules.  This  results 
in  more  stable  microcode,  since  a "bug"  fixed  in  any  one  application  will  be 
automatically  applied  to  all  BCU's. 


INTRODUCTION 

The  continuing  evolution  of  digital  processor  technology  as  applicable  to 
aircraft  data  bus  systems  has  stimulated  significant  advances  in  the  flexibility 
and  capability  of  the  data  bus  interface  unit.  The  continued  improvement  of 
component  and  circuit  technologies  has  permitted  the  data  bus  hardware 
designer  to  achieve  these  results,  and  the  added  benefits  of  higher  reliability, 
lower  cost,  and  improved  adaptability. 

A "family  tree"  of  SCI's  FMTI  products  is  presented  in  Figure  1.  It 
shows  that  the  BCU  is  a natural  continuation  of  development  activities  in 
multiplex  technology  dating  back  to  1966,  A comparison  of  detailed  function, 
size,  and  power  characteristics  of  the  FMTI  products  is  given  in  Figure  2, 
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FMTI  EVOLUTION  AT  SCI 


Ik 


Bi- Phase  Modulation 
Livalid  Sync  Code 
SPDP/NASA  -MSFC 
1968 


Integrated  BCIU 
PROM  Format  Decoding 
DHS/USAF-WPAFB 
1973 


All  Digital  Receiver 
MTU/USAF-WPAFB 
1974 


FMTI  SPECIFICATIONS 


PRODUCT  FUNCTION  NUMBER  IC  COUNT  SIZ^E  POWER 

RECEIVERS/  14, 16, 20/. 0 (in^)  (W) 

TRANSMITTERS 


MTI-110 

Bus  Modem 

1/2 

63/0 
flat  pack 

24 

5W 

A MUX 

RT  Interface  to 

1/1 

7H/0 

75 

14  W 

Host  Memory 
via  DMA 

flatpack 

BCU-400 

BC/RT  Interface 

1/2 

138/5 

96 

18W 

to  Host  Memory 
via  DMA 

DIP 

FUNCTIONAL  DESCRIPTION 


A BCU  Interfaces  a host  processor  to  dual  MIL-STP- 1SS3A  data  busses. 

It  has  two  basic  functions:  communicating  with  the  host  processor  via  pro- 
grammed I/O  (PIO)  and  interrupts,  and  transferring  data  to  or  from  the 
bus  via  direct  memory  access  (DMA).  Normally,  tliese  functions  are  mutually 
exclusive  - the  BCU  cannot  be  Initialized  or  Interrogated  while  engaged  in 
bus  activity.  However,  the  BCU  status  register  can  be  read  and  a shutdown 
request  issued,  at  any  time  by  tlie  host  processor.  Also,  device  flags  can 
be  tested,  if  provided  in  the  host's  architecture. 

Before  it  can  commence  data  transfers,  the  BCU  must  be  initialized. 

'I’his  involves  setti]\g  the  contents  of  at  least  two  internal  registers -operation 
mode  and  activity  pointer  - by  PIO  commands.  Other  registers  maybe 
required  in  certain  operating  modes. 

After  initialization,  the  interface  operates  by  interpreting  the  content i-  > v 
a aeries  of  channel  control  blocks  (COB)  obtained  from  the  host  memory  via 
DMA.  Each  CCB,  containing  interface  directives,  MIL-STD- 1 SFi^A  text,  and 
a link  to  the  successor  block  in  the  chain,  provides  svifficient  Information  to 
enable  the  BCU  to  operate  without  further  host  intervention.  The  BCU  then 
executes  the  transfers  specified  by  successive  CC.B's  until  tlie  chain  is 
exhausted  or  an  error  is  detected  in  a bus  transmission.  In  either  case,  a 
maskable  Interrupt  is  generated  by  the  BCIT,  and  bus  data  transfer  ceases. 

Both  the  host  device  code  and  the  RT  address  can  be  specified  by 

field-alterable  straps.  This  is  useful  when  multiple  BCU's  are  installed  in 
a single  host,  A default  operating  mode  can  be  selected  on  the  board,  to 
facilitate  operation  of  multiple  units  on  the  same  bus  with  common  software. 

All  switch  settings  are  accessible  to  the  driver  software. 

When  operate<l  in  the  MIL.-STD- 1 ''‘'3A  cotnmaiul  response  tnode,  the  lU'U 
can  act  either  as  a bus  controller  (B('),  in  which  it  initiates  all  information 
transfers,  or  as  one  or  more  remote  terminals  (RT),  which  can  exchange  data 
with  the  bus  controller  or  another  RT.  If  the  nuiltiple  RT  option  is  incUnlcd. 
however,  a given  BCU  cannot  function  as  both  the  sending  and  receiving  R' 
in  a terminal-to-terminal  transfer. 

ARCHITFCTURK 

The  Bt'U  hardware  is  organized  into  three  primaiv  elements;  a serial 
digital  interface  with  dual  MIL-STD- 1 lA  data  busses,  an  infernal  •)  MHr 
16  bit  microprocessor  atul  associated  logic,  atnl  a parallel  interface  with 
the  host  processor.  Figure  3 is  a block  diagranr  of  the  lU'U  showing  the 
majo"  functional  blocks. 


BCU  BLOCK  DIAGRAM 


HOST  INTERFACE  PROCESSOR  BUS  INTERFACE 


Host  Interface 


The  host  interface  contains  three  full-width  registers  which  are  shared 
among  DMA,  PIO  and  INT  functions.  This  allows  DMA  operations  to  use  the 
address  and  data  registers  and  PIO  reads  to  access  the  status  register  while 
the  ECU  is  executing  CCB's.  Obviously,  the  DMA,  PIO,  and  INT  control 
logic  must  be  tailored  to  the  particular  application,  but  this  involves  less 
than  20%  of  the  ECU  hardware  design. 

DMA  control  is  performed  by  independent  hardware  on  all  ECU's  because 
the  timing  requirements  exceed  the  response  time  of  the  nP.  Control  infor- 
mation consists  of  DMA  read/DMA  write  commands  and  a busy  flag.  ECU 
operation  is  largely  unaffected  by  changes  in  DMA  latency  or  transfer  rate. 
Long  latency  times  (19  ns  max)  can  be  tolerated  in  the  EC  mode  at  the  cost 
of  longer  intermessage  gaps.  Latency  times  for  successful  execution  of  the 
RT  mode  can  be  no  greater  than  11  gs.  If  a DMA  request  is  not  honored  i 
time,  the  firmware  will  request  an  interrupt  after  setting  the  appropriate 
bit  in  the  status  register. 

PIO  control  is  performed  in  firmware  wherever  feasible  to  reduce  parts 
count.  Obviously,  the  status  input  and  shutdown  commands  are  decoded  in 
hardware  to  permit  jjP  independence.  The  PIO  software  interface  is  elegai.t 
on  asynchronous  machines,  such  as  the  PDP/LSI-11  family.  In  synchronous 
environments  (NOVA , V77)  the  software  interface  is  non-standard,  because 
ECU  status  must  he  tested  before  issuing  a new  PIO  request  to  avoid  possible 
overrun  conditions.  Many  architectures  include  a series  of  device  control 
and  sense  flags  which  can  be  directly  utilized  for  this  purpose. 

Interrupt  control  is  also  achieved  by  dedicated  hardware  because  of 
response  time  constraints. 

Processor 

The  jiP  employs  bipolar  bit  slices  (2901)  to  achieve  4 MHz  instruction 
cycle  times.  It  features  a pipeline  register  at  the  PROM  output,  full  carry 
look-ahead,  16  bit  shift/rotate  operations,  and  a 32  word  mask  PROM  to 
allow  single  bits  or  selected  fields  to  be  isolated  in  a single  microcycle. 
Microcode  size  is  IK  x 40  bits,  with  expansion  possible  to  4K  words,  since 
a 12  bit  instruction  address  space  is  standard. 

Two  classes  of  micro-instructions  redefine  the  40  bit  instruction  word, 
ALU  instructions  use  39  bits  to  specify  operation  code,  register  selects, 
data  input  source,  output  destination,  mask  selection,  and  shift  type.  They 
pass  control  only  to  the  next  sequential  micro-instruction.  Sequencer 
ins'  ictions  use  between  28  and  32  bits  to  control  next  address  generation. 
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The  full  complement  of  ZMlO/ZPll  address  control  orders  is  supported, 
including  two  and  three-way  conditional  branches,  subroutine  resting  to  four 
levels,  conditional  looping  to  a count  of  102  3,  and  vector  branches. 

An  assembler  and  support  software  package  was  constructed  to  aid  in  firm- 
ware development.  The  assembler  features  an  easily  comprehensible  input 
format;  the  resulting  code  can  be  followed  without  consulting  detailed  flow- 
charts. The  firmware  is  organized  into  functional  blocks:  PIO  handlers 
diagnostic  mode,  BC  mode,  RT  mode,  and  support  subroutines  are  all 
maintained  as  separate  modules.  These  are  assembled  separately  and  the 
relocatable  object  code  is  linked  to  form  a load  module  and  PROM  program- 
ming tape.  A sample  of  the  source  code  is  given  in  Figure  4. 

1553  Bus  Inte r f ace 


The  serial  interface  provides  all  functions  specified  by  MIL-STD- 1 5'^ ^ 
including  signal  characteristics,  bus  loading,  and  data  validation.  The 
transmitter,  under  processor  control,  provides  a MIL-STI-)-  1 553A  output 
signal  with  specified  amplitude,  rise/fall  time,  output  noise,  and  trans- 
mission rate  into  a twisted  shielded  pair  data  bus  with  up  32  remote 
terminals.  The  design  provides  for  short  stub  or  long  stub 
strap  option  and  provides  transformer  isolation  to  the  b 
of  the  bus  interface  are  available.  The  standard  design,  v 
radiation-hardened,  consists  of  two  receivers  and  a single 
structed  from  TTL  MSI.  A later  design  incorporates  two  im  . - lu  t.Mu.'i 
encoder/decoder  LSI  circuits  to  achieve  active  standby  operation,  where  a 
valid  command  word  on  one  bus  will  abort  a transaction  on  the  second  bus 

o*'  all  designs.  Waveform  shaping  per  MIX 
can  be  provided  as  an  optional  feature. 


pe ration  as  a 
wo  versi  ons 
'.tn  be 
con- 
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BCU  OPERATION 


After  the  BCU  has  received  PIO  commands  to  preset  the  necessary 
internal  registers,  and  received  a start  command  from  the  host  processor 
It  commences  operation  in  the  selected  mode.  One  or  more  channel  control 
blocks  effect  the  actual  data  transfer  operations  of  the  BCU.  Each  CCB 
contains  a 16  bit  pointer  its  successor,  which  can  be  located  anywhere  in 
meniory.  The  BCU  continues  processing  CCB's  until  it  recognizes  an  end- 
of-chain,  or  detects  an  error  condition,  or  is  halted  by  a shutdown  command 
from  the  processor.  Each  CCB  is  composed  of  a two  word  header,  containing 
a charnel  control  word  (CCW)  and  the  link  address.  The  remainder  of  the 
CCB  depends  on  the  operating  mode  and  is  defined  in  the  following  paragraphs. 
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'I'lie  c:cw  format  is  given  In  Figure  5.  The  MSB  of  the  CCW  is  the  CCB 
skip  bit,  which  when  set,  causes  the  BCU  to  ignore  the  current  CCB  and 
continue  to  the  successor  CCB.  Bits  8-14  of  the  CCW  control  interrupt 
generation.  The  remaining  bits  specify  error  generation  options,  transmitter  and 
receiver  selection,  and  two  bits  of  option  code  uniquely  defined  for  each 
operational  mode. 

The  second  word  in  a CCB  is  always  the  link  address.  This  gives  the 
address  of  the  next  CCB  in  the  chain.  If  the  skip  bit  is  set  in  the  CCW,  the 
BCU  immediately  chains  to  the  successor  CCB  without  executing  the  current 
one.  Also,  if  the  stop  bit  is  set,  the  BCU  requests  an  interrupt  without 
executing  the  remainder  of  the  CCB. 

Off  Mode 

Off  Mode  operation  is  used  for  diagnostic  purposes  and  does  not  resui. 
in  information  transfer  on  the  data  bus.  While  the  BCU  is  in  the  off  mode, 
all  internal  registers  may  be  read  and  written,  and  switch  settings  may  be 
read.  In  this  mode,  the  I/O  data  transfer  to  all  internal  registers  may  be 
verified,  and  the  BCU  can  be  initialized  for  the  other  operating  modes. 

Bus  Controller 

In  this  operational  mode  the  BCU  acts  as  a MIL-STD- 1553A  bus  controller 
(BC)  with  the  capability  to  transmit  or  receive  data  from  RT's  or  to  initiate 
RT  to  RT  transfers  and  optionally  capture  their  data. 

The  BC  CCB  format  is  given  by  Figure  6.  In  addition  to  the  control  word 
and  link,  the  CCB  header  contains  a pointer  to  the  message  data  area  and  the 
number  of  data  words  (DWC)  to  be  transmitted  or  received.  A zero  in  the 
word  count  field  indicates  that  no  words  with  data  sync  are  to  be  transmitted 
or  received.  The  retransmit  count  specifies  the  number  of  retries  to  be 
attempted  in  the  case  of  a transmission  error.  If  the  message  is  successtully 
transferred  before  the  count  decrements  to  zero,  an  error  interrupt  will 
not  be  generated,  even  if  enabled  in  the  CCW. 

The  stored  message  consists  of  a header  containing  the  actual  command 
word  to  be  transmitted,  followed  by  a word  reserved  for  the  received  status 
response.  In  the  case  of  RT-RT  transfers,  two  commaind  words  and  status 
areas  are  necessary.  Message  data  words  may  follow  the  header,  or  may 
appear  anywhere  in  the  host  memory.  Note  that  the  data  pointer  in  the  CCB 
header  must  be  the  address  of  the  first  data  word  to  be  transmitted,  or  point 
to  a buffer  large  enough  to  contain  the  received  data  words. 
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CHANNEL  CONTROL  WORD 


I ! 

I 


Bit  15  (MSB)  Skip  this  CCB  if  set. 

Bit  8-14  Interrupt  Generation.  Generate  a CPU  interrupt  as 

defined  below: 


Bit  4-7 


Bit  3 


Bit  2 


Bits  0-1 


Bit  14  set: 
Bit  13  set: 

Bit  12  set: 

Bit  11  set: 

Bit  10  set: 

Bit  9 set: 

Bit  8 set: 


Interrupt  CPU  immediately. 

Interrupt  CPU  if  the  BCU  status  register 
indicates  a transmission  error. 

Interrupt  CPU  if  the  RT  Message  Error  flag 
is  set  in  the  status  word. 

Interrupt  CPU  if  RT  Terminal  flag  is  set  in 
the  status  word. 

Interrupt  CPU  if  a bit  is  set  in  3 MSB  of  RT 
Status  Codes. 

Interrupt  CPU  if  a bit  is  set  in  3 middle  bits  oi 
RT  Status  Codes. 

Interrupt  CPU  if  a bit  is  set  in  3 LSB  of  RT 
Status  Codes. 


Error  Block  Generation.  Generate  an  invalid  message  as 
specified  below: 


Bit  7 set : 
Bit  6 set: 
Bit  5 set: 
Bit  4 set: 


Bad  sync  in  data,  command  and  status  words. 
Bad  parity  in  data  words. 

Bad  parity  in  command /status  words. 

Inhibit  transmitter  timeout  (shutdown). 


T ran  emitter  Selection 


Bit  3 set:  Transmit  on  secondary  bus. 

Bit  3 clear:  T ransmit  on  primary  bus. 

Receiver  Selection 


Bit  2 set:  Receive  on  both  busses. 

Bit  2 clear:  Receive  on  transmit  bus  only. 

Option  Code. 


Figure  5 
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The  function  to  be  performed  by  the  BCU  in  the  BC  mode  is  specified  by 
the  option  code  in  the  CCW.  Codes  are  specified  for  BC  to  RT  and  RT  to 
BC  information  transfer,  as  well  as  RT  to  RT  with  and  without  the  copy  option. 

Remote  Terminal 

In  the  RT  operation  mode,  the  BCU  acts  as  a MIL-STD- 1553A  remote 
terminal  with  Subaddress  recognition  capability.  The  BCU  can  either  tran- 
smit data  to  a BC  or  receive  data  from  the  BC,  depending  on  the  state  of  the 
T/R  bit  in  the  command  word  it  receives.  An  internal  register  is  provided 
to  specify  the  maximum  time  (in  microseconds)  that  the  data  bus  can  be  idle 
without  generating  an  interrupt.  This  feature  is  enable  in  the  CCW  option 
field. 

The  RT  CCB  format  is  given  in  Figure  7.  The  CCB  header  contains  the 
CCW,  link,  and  status  word  skeleton.  The  skeleton  is  OR'ed  with  the  parity 
error  detect  and  RT  bus  address  before  being  transmitted  back  to  the  BC. 

Thus  except  for  BIT  purposes  the  user  should  ensure  that  only  the  10  LSB's 
are  set  in  the  skeleton  word.  Also,  this  skeleton  is  updated  whenever  any 
command  word  is  detected  on  the  bus;  thus  to  change  the  transmitted  RT 
status  word,  the  user  need  only  to  store  a new  skeleton  in  the  CCB. 

The  remainder  of  the  CCB  consists  of  64  four-word  entries,  one  for  each 
Subaddress  T/R  pair.  The  first  word  of  the  entry  is  the  address  of  the  data 
area  while  the  second  is  a message  counter.  If  the  data  pointer  for  a parti- 
cular combination  is  zero,  a BC  reference  to  this  combination  will  generate 
an  interrupt.  If  the  pointer  is  all  ones,  the  reference  will  be  ignored  by  the 
BCU,  causing  a message  error  to  be  detected  by  the  BC.  If  enabled  in  the 
CCW  the  message  counter  is  decremented  whenever  a combination  is  refer- 
enced. When  the  counter  becomes  zero,  an  interrupt  is  generated.  This 
is  useful  when  a particular  combination  is  to  be  accessed  a specified  number 
of  times.  The  last  two  words  of  each  entry  are  reserved  for  future  expansion. 

If  the  timeout  counter  is  enabled,  a dead-line  detected  for  longer  than  the 
specified  period  will  generate  an  interrupt.  The  message  counter  and  time- 
out updates  are  controlled  by  the  CCW  option  code. 

The  BCU  can  operate  in  full  compliance  with  MIL-STD-  1 553A  require- 
ments for  RT  operation,  including  the  optional  mode  control  feature.  The 
mode  control  can  be  accomplished  by  zeroing  the  data  pointer  for  subaddress 
0 to  transmit  and  receive  in  the  CCB.  This  will  generate  an  interrupt 
whenever  SA  0 is  referenced  by  the  BC.  Measured  response  time  to  a BC' 
command  word  is  4.8  fts. 


REMOTE  TERMINAL 
CCB  FORMAT 


It  should  be  noted  that  ihe  'RCU  will  remain  in  a particular  RT  CCB  for 
an  indefinite  time;  it  will  enter  a new  C('B  only  when  commanded  by  the  Cl'li, 
unless  the  skip  or  stop  bits  are  set  in  the  CCW. 

Multiple  Remote  Terminal 

This  mode  allows  the  BCU  to  respond  to  command  words  for  up  to  31 
remote  terminals,  as  long  as  it  is  not  participating  in  both  the  transmit  and 
receive  functions  of  a terminal-to-terminal  message.  It  is  an  expanded  form 
of  RT  mode  operation,  and  the  same  internal  registers  are  provided.  The  CCB 
for  the  MRT  mode  consists  of  a CCW,  a link  word,  and  one  or  more  RT  CCB's. 
The  format  of  the  included  CCB's  is  identical  to  that  in  the  RT  mode  for 
standardization,  but  obviously  the  control  words,  and  links  are  ignored. 

If  a bus  error  is  detected,  the  BCU  status  and  transmission  status  will  he 
written  into  the  CCB,  as  well  as  the  terminal  address  and  subaddress  of  i.tv  • 

RT  detecting  the  error,  and  the  subaddress  pointer.  The  CCB  format  is 
given  in  Figure  8. 

Before  initiating  MRT  operation,  the  number  of  terminals  to  be  simulated 
must  be  set  in  an  internal  register.  The  BCU  then  determines  the  actual 
terminal  addresses  from  the  included  CCB's. 

Diagnostic 

This  operation  mode  permits  the  CPU  to  verify  the  BCU  internal  data  paths 
at  three  levels:  DMA,  transmitter/receiver  logic,  and  transmitter/receiver 
analog  signals.  Five  tests  are  performed  in  this  CCB,  and  the  format  is  to 
read  one  or  more  words  from  the  test  input  buffer,  route  them  through  the 
specified  data  path,  and  write  them  back  to  the  test  ovitput  buffer.  The  CPU 
can  them  compare  corresponding  pairs  of  input  and  output  test  words.  In 
all  tests,  the  output  buffer  size  must  be  twice  the  input  buffer  size,  since 
tests  2-5  also  output  the  BCU  transmission  register,  and  test  1 adds  the  BCl' 
status  register.  The  size  of  each  input  buffer  is  specified  in  the  CCB  header, 
and  can  range  from  0 to  255.  Note  that  this  allows  the  transmitter  shutdown 
feature  to  be  checked  by  tests  4 and  5. 

The  CCB  format  is  given  in  Figure  9.  Note  that  for  test  1,  the  output 
buffer  pair  includes  the  DMA  echo  word  and  the  BCU  status  register  contents, 
while  tests  2-5  write  oit  the  test  result  and  the  BCU  transmission  status 
register  contents  for  every  input  word.  A short  description  of  each  test  follows. 

Test  1:  The  ^P  reads  a word  from  input  buffer  1 and  writes  it  to 

output  buffer  I.  This  tests  DMA  input  and  output  functions, 
as  well  as  Internal  data  paths.  If  a noncompare  results,  the 
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CPU  can  isolate  the  problem  to  either  DMA  input  or  DMA 
output  registers  via  PIO  tests  if  the  jiP  is  functioning. 

Test  2;  Words  from  input  buffer  2 are  formatted  by  the  transmitter 
control  logic  and  routed  to  the  receiver,  bypassing  the 
transmitter  output.  The  words  are  formed  with  data  sync. 
This  test  validates  the  transmitter  and  receiver  logic  for 
D-type  sync  without  appearing  on  the  outpiA  data  bus. 

Test  3:  This  is  basically  the  same  as  test  2,  except  that  command 

sync  is  used.  This  test  validates  the  transmitter  and  receiver 
logic  for  C-type  sync. 


Test  4:  Words  from  input  buffer  4 are  transmitted  on  the  data  bus 

with  D-type  sync,  with  the  receiver  enabled.  The  received 
data  is  written  to  output  buffer  4.  This  tost  validates  the 
transmitter  output  stage  and  receiver  front-end  for  D-type  sync. 

Test  5;  This  test  resembles  ^4,  with  the  substitution  of  C-type  sync. 

This  test  validates  the  transmitter  output  stage  for  C-type 
sync. 


BCU  APPLICATIONS 


The  BCU  design  and  architecture  is  compatible  with  most  of  todays 
MIL-STD- 1553A  avionics  equipments.  The  micro  - programmability  feat  u res 
of  the  BCU  enable  the  unit  to  be  tailored  to  meet  different  user  requirements 
primarily  via  firmware  modification.  Hardware  changes  are  only  required  at 
the  subsystem  interface  and  of  course  repackaging  is  required  to  meet  the 
user  mechanical  configuration. 

Due  to  similarities  in  architecture  and  compatibility  of  subsystem  inter- 
faces. the  BCU  has  gained  widespread  acceptance  in  the  avionics  processor 
community.  SCI  under  an  exclusive  purch<i»e  agreement  with  ROLM 
Corporation  (1)  has  adapted  the  BCU  concept  to  provide  a MIL-STD- 1 553A 
interface  for  the  ROLM  1600  series  military  computers.  A photograph  of 
this  two  card  ROLM  set  is  shown  in  Figure  10.  In  consortium  with  Sperry 
t^nivac  Minicomputer  Division,  the  BCU  has  been  adapted  to  the  Sperry 
V77-400  series  minicomputers.  A photograph  of  a brassboard  unit  delivered 
l*»  Sperry  ih  shown  in  Figure  11. 

* Svrmission  for  disclosure  ^ranted  by  ROLM  Corporation,  Santa  Clara, 

♦ life  mia. 

' t.astor  for  disclosure  granted  by  Sperry  llnivac  Minicomputer  Division, 
-•ec  *1  fornia. 
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Additional  applications  of  the  BCU  in  various  stages  of  development 
are  Illustrated  in  Table  1.  Each  of  these  applications  employ  the  same 
design  differing  only  in  the  host  interface  packaging  configuration. 
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BC  Bus  Controller 

BCU  Bus  Control  Unit 
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CCW  Channel  Control  Word 

DMA  Direct  Memory  Access 

DWC  Data  Word  Count 

FMTI  Flexible  Multiplex  Terminal  Interface 

INT  Interrupts 

MTI  Multiplex  Terminal  Interface 

MRT  Multiple  Remote  Terminal 

PIO  Programmed  Input /Output 

RT  Remote  Terminal 

SA  Subaddress 

T/R  Transmit /Receive 
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THE  DESIGN  AND  DEVELOPMENT  OF  AN  LSI 
PUS  INTERFACE  UNIT 
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Major  Gary  Pritchard 


Air  Force  Avionics  Laboratory 
Wright-Patterson  Air  Force  Base,  Ohio 


ABSTRACT 


The  Air  Force  Avionics  Laboratory  (AFAL)  is  sponsoring 
an  ongoing  contractual  program  with  Harris  Corporation, 

GISD,  Melbourne,  Florida  for  the  design  and  development,  and 
demonstration  of  an  LSI  Chip-set  Bus  Interface  Unit  (BIU) . 
The  resulting  design  will  comply  with  MIL-STD-1553B. 
Additional  flexibility  will  be  available  due  to  the  use  of 
DAIS-like  data  registers  and  pointer  tables  used  for  host 
interfacing.  The  functional  partitioning  of  the  two  chip- 
set  is  such  that  most  Remote  Terminal  (RT)  requirements  can 
be  fulfilled  by  the  first  chip  (BIU  #1)  alone,  while  both 
chips  (BIU  #1  and  BIU  #2)  can  be  used  to  implement  the  Bus 
Controller  function.  The  chip-set  is  designed  to  replace 
nearly  all  of  the  logic  between  the  multiplex  bus  analog  to 
digital  interface  and  the  host  (or  host  processor)  back  bus. 
The  chip-set  will  be  second  sourced  by  Intersil. 

This  paper  conveys,  in  a general  sense,  the  design  of 
the  LSI  BIU  chip-set.  A discussion  of  the  problems  and 
resulting  trade-offs  which  must  be  made  are  presented.  Not 
only  were  technology  trade-offs  made,  but  more  importantly, 
bus  system  protocol  trade-offs  affected  the  BIU  design.  The 
very  detailed  technical  details  have  been  reserved  for  pre- 
sentation in  the  accompanying  paper  entitled  "An  Adaptable 
LSI  Chip-Set  for  Use  on  Multiplex  Data  Bus  Systems," 
presented  by  Harris  Corporation. 
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BACKGROUND 


The  Air  Force  Avionics  Laboratory  (AFAL)  is  sponsoring 
the  development  of  a large  scale  integrated  (LSI)  bus  inter- 
face unit  (BIU)  for  implementing  MIL-STD-1553  multiplex 
data  buses.  The  BIU  development  is  part  of  an  AFAL  technology 
base  development  project  which  strives  to  exploit  LSI  tech- 
nology to  the  advantage  of  military  avionics  systems  by 
identifying  common  functions  which  have  wide  intersystem 
applicability  and  making  these  functions  available  as  LSI 
circuits  to  system  developers.  The  total  BIU  development 
program  includes  in-house  development  of  a preliminary 
specification,  contractual  development  of  the  BIU  LSI  circuits 
including  production  by  the  prime  source  and  establishment 
of  a second  source,  functional  demonstration  of  BIU  capability, 
and  military  qualification  and  nuclear  radiation  response 
characterization . 

Harris  Government  Information  Systems  Division, 

Melbourne,  Florida  was  awarded  a contract  in  August  1977 
for  designing  and  developing  the  LSI  BIU.  To  assure  the 
BIU  satisfies  tri-service  requirements,  representatives  from 
Army  and  Navy  as  well  as  from  Air  Force  organizations  have 
participated  in  periodic  design  reviews.  The  original  design 
goal  was  a single  LSI  chip  which  could  operate  in  several 
modes  including  operation  in  a stand  alone  remote  terminal, 
a fixed  sequence  terminal,  a smart  terminal,  or  in  a bus 
controller.  Functionally  the  BIU  was  to  be  fully  compatible 
with  both  MIL-STD-1553A  and  DAIS  (Digital  Avionics  Information 
System)  protocol  and  incorporate  functions  for  future 
requirements  not  presently  included  in  MIL-STD-1553A. 

During  the  BIU  development  these  goals  were  modified. 

It  was  found  that  all  required  functions  could  not  be 
economically  realized  on  a single  LSI  chip  using  Harris's 
silicon  gate  CMOS  process.  A cost-effective  two-chip  design 
evolved  where  chip  #1  incorporates  the  functions  required 
for  a remote  terminal  and  chip  #2  incorporates  the  additional 
functions  required  for  a bus  controller.  Also  the  BIU  design 
schedule  coincided  with  the  period  when  the  B revision  to 
MIL-STD-1553  was  being  formulated.  After  careful  review  of 
the  present  and  potential  future  users,  MIL-STD-1553B  was 
chosen  as  the  baseline  for  the  BIU  design.  Where  appropriate 
the  MIL-STD-1553B  mode  codes  are  implemented  directly  by  the 
LSI  BIU  chips.  The  present  BIU  design  is  the  result  of 
several  trade-off  decisions.  The  complexity  of  the  chips 
could  have  been  decreased  at  the  expense  of  requiring 
additional  support  circuitry  for  each  use  of  the  BIU  chips. 
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More  flexibility  could  have  been  incorporated  by  using 
external  ROMs  to  define  the  protocol  for  each  application, 
but  this  again  would  represent  an  additional  cost  to  the 
system  users.  The  present  BIU  design  is  compliant  to 
MIL-STD-1553B,  uses  the  DAIS  defined  stored  program  technique, 
data  buffer  structure,  automatic  (progammable)  message  retry 
capability  and,  in  general,  reflects  the  DAIS  back-bus  pro- 
tocol. The  low  power  Schottky  TTL  compatible  BIU  can  serve 
as  a DMA  controller  between  the  random  access  memory  of  the 
host  computer  in  a smart  computer,  or  be  capable  of  perform- 
ing the  functions  required  for  stand-alone  operation  in  the 
case  of  a remote  terminal. 

GENERAL  DESCRIPTION 

The  LSI  chip-set  is  designed  to  perform  the  interface 
functions  between  the  multiplex  bus  analog  receiver/ 
transmitter  unit  and  the  host  electronics.  The  analog 
receiver/transmitter  (R/T)  unit  is  the  set  of  electronics 
which  convert  the  manchester  signals  on  the  multiplex  bus, 
be  it  fiber  optic,  twisted  pair,  or  coax,  to  logically 
equivalent  CMOS  compatible  signals  which  the  BIU  can  process. 
Also,  the  R/T  interface  contains  the  mux  bus  line  drivers 
which  allow  the  BIU  to  transmit  data.  The  driver  circuits 
in  the  unit  must  be  able  to  accept  the  bipolar  zero  and 
bipolar  one  output  signals  from  the  BIU  and  drive  the 
appropriate  mux  bus  line  drivers.  The  R/T  interface  may 
contain  filters  to  condition  the  mux  bus  signals,  depending 
on  the  system  design  specifications.  The  R/T  unit  does  not 
process  the  sync  or  data;  this  is  accomplished  by  the  BIU. 

The  host  electronics  consists  of  the  system  or  subsystem  which 
needs  communication  via  the  mux  bus.  The  host  may  or  may  not 
contain  memory,  although  for  most  applications  the  host  will 
consist  of  at  least  one  processor  and  will  contain  memory 
which  will  be  used  for  message  buffering.  Figure  One  depicts 
the  mux  bus/BIU/host  interconnection. 

The  input  to  the  BIU  will  accept  a serial  unipolar 
representation  of  the  bi-phase  data  and,  on  the  output, 
generates  the  logical  equivalent  of  serial  bi-phase  data. 

At  the  host  elect^'onics  interface,  the  BIU  accepts  instruc- 
tions from  the  host  and,  by  way  of  these  instructions 
transfers  parallel  data  to  and  from  the  host.  The 
received  data  can  be  used  immediately,  or  it  can  be  stored, 
under  DMA  control,  in  the  memory  of  the  host  for  use  at  a 
later  date.  Status  information  is  conveyed  to  and  from  the 
BIU  by  means  of  dedicated  status  linos  and  access  to  internal 
status  registers. 
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Two  major  operating  modes  are  available  in  the  BIU: 

(1)  In  the  Remote  Terminal  (RT)  mode  the  BIU  is  respon- 
sive to  the  mux  bus  as  the  major  driving  source  of  BIU 
activity,  and  (2)  The  BIU  in  the  Controller  mode  is 
responsive  to  both  the  requirements  implied  by  tne  mux  bus 
and  the  requirements  supplied  by  the  host.  These  two 
operational  modes  are  reflected  in  the  logical  partitioning 
of  the  BIU  chip-set.  The  first  chip,  BIU  #1,  can  act  as  a 
stand-alone  unit  for  use  in  RTs.  For  the  additional  capa- 
bility required  by  the  controller  function,  the  second  chip, 
BIU  #2,  is  used  to  enhance  the  operation  of  BIU#1.  Working 
together  as  a chip-set  provides  the  full  protocol,  including 
mode  codes,  of  MIL-STD-1553B  and  provides  the  register  and 
data  handling  flexibility  of  a DAIS-like  system. 

The  basic  block  diagram  for  BIU  #i  is  given  in  Figure 
2.  The  manchester  decoder  provides  synchronization  with  the 
incoming  manchester  data  and  feeds  the  rest  of  the  chip-set 
separated  data  and  clock.  The  manchester  encoder  adds  the 
appropriate  sync  type  and  parity  to  the  data  and  transmits 
the  result  to  the  mux  bus  line  driver  circuit.  Both  the 
manchester  encoder  and  decoder  are  usable  over  a baseband 
rate  of  1 to  5MHz.  The  Instruction  Decode  and  Execution 
block  is  used  to  initialize  Chip  #1,  and  to  drive  it  as 
required  in  the  Bus  Controller  mode  by  Chip  #2.  The  Instruc- 
tion Encode  and  Execution  Logic  allows  Chip  #1  to  convey  the 
status  on  its  internal  operation,  such  as  message  received 
and  message  complete.  The  Error  Detection  Logic  constantly 
monitors  the  integrity  of  the  received  messages.  Conditions 
such  as  message  too  long,  message  too  short,  parity  error, 
and  manchester  bi-phase  errors  are  reported  to  the  host. 

The  Parallel  Interface  Logic  can  be  configured  to  operate 
with  either  an  8 or  16  bit  host  system. 

BIU  #2  is  block  diagrammed  in  Figure  3.  The  basic 
design  is  a register  stack  with  appropriate  control  logic. 

BIU  #2  is  used  to  enhance  the  operation  of  BIU  #1.  It  can 
drive  BIU  #1  and  the  two  chips  thereby  implement  the  Bus 
Controller  function.  When  used  with  BIU  #1,  the  input  and 
output  control  lines  of  BIU  #2  are  split  into  two  groups: 
those  to  and  from  the  host,  and  those  to  and  from  BIU  #1. 

The  I/O  data  bus  is  shared  between  BIU  #1,  BIU  #2,  and  the 
host.  The  basic  interconnection  structure  is  given  in 
Figure  1. 

Each  of  the  BIU  chips  is  packaged  in  a 40  pin  dual  in 
line,  or  a 40  pin  hermetic  chip  carrier.  The  units  require 
a single  5 volt  power  supply.  The  voltage  level  of  the 
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power  supply  is  constantly  monitored  by  BIU  #1  and  if  a 
glitch  occurs  BIU  #1  will  reset  itself  to  a default  "quiet" 
state.  This  reset  condition  is  conveyed  to  the  host  and 
BIU  #2  so  that  the  decision  whether  to  re-initialize  the 
BIU  can  be  made. 

With  both  chips  interconnected,  the  resulting  BIU  unit 
is  responsive  to  the  mode  codes  of  MIL-STD-1553B.  Although 
many  of  the  mode  codes  are  acted  upon  internal  to  the  BIU, 
all  of  them  are  passed  on  to  the  host.  Those  which  require 
further  action,  or  those  which  the  BIU  cannot  interpret,  can 
be  processed  by  the  host.  In  addition,  DMA  indirect  access 
and  storage  of  data  is  accomplished  through  the  use  of 
pointer  blocks,  and  message  scenario  control  is  accomplished 
by  the  use  of  instruction  word  pairs  which  are  fetched  and 
interpreted  by  the  BIU  Chip-set. 

SUMMARY 

The  design  of  the  LSI  BIU  Chip-set  provides  hardware 
support  for  MIL-STD-1553B,  although  this  was  not  the  only 
goal  of  the  program.  The  prime  impetus  was  the  design  and 
development  from  two  sources  of  a useful  LSI  Chip-set  for 
the  interfacing  of  avionics  subsystems  to  multiplex  data 
buses.  Because  of  the  wide  support  from  industry  and  the 
military  for  MIL-STD-1553B,  it  was  chosen  as  the  baseline 
for  the  BIU  design.  Additional  capability  similar  to  that 
used  in  DAIS  protocol  was  added  for  increased  utility.  Con- 
tributions added  from  the  DAIS  architecture  were  such  things 
as  indirect  access  of  data  via  pointer  tables,  programmability 
through  the  use  of  two  word  instruction  pairs,  and  the  use 
of  a shared  input/output  bus  structure. 
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Figure  2.  BIU  #1  BASIC  BLOCK  DIAGRAH 
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THE  BUS  INTERFACE  UNIT 
AN  ADAPTABLE  LSI  CHIP-SET 

Daniel  G.  Yelverton 

Harris  Corporation, 

Government  Information  Systems  Division 


1.0  Bus  Interface  Unit  (BIU) 

1.1  The  BIU  is  an  LSI  approach  to  the  implementation 
of  tlie  interface  between  the  host  electronics  and  the  1553B 
mauchester  data  bus.  A two  chip  approach  was  used  due  to 

the  complexity  of  the  system.  One  chip,  BIU  #1,  can  act  as 
a stand-alone  unit  for  use  in  a less  complex  system  such  as 
a remote  terminal  (RT) . Where  an  additional  capability  is 
needed,  the  second  chip,  BIU  #2,  is  used  to  enhance  the 
operational  capability  of  BIU  #1.  The  following  discussion 
will  describe  the  use  of  1)  BIU  #1  as  a stand-alone  unit,  and 
2)  BIU  #1  with  BIU  #2  as  a chip-set. 

1.2  BIU  #1  has  many  unique  features  which  extend  its 
system  applicability.  For  instance,  baseband  data  rate  of 

1 to  5 MHz;  internal  error  checking;  internal  Busy  mode; 
can  almost  completely  handle  activity  between  the  host  and 
the  1553  data  bus.  Figure  1.2-1  shows  the  basic  block  diagram 
of  BIU  #1  and  Figure  1.2-2  shows  the  functional  pin  outs  of 
BIU  #1. 

1.2.1  Initialization  of  BIU  #1  to  operate  in  the 

Controller  mode  is  accomplished  by  enabling  the  control  word 
onto  the  I/O  bus  and  strobing  the  "Code  Execute  Strobe" 
input.  The  BIU  is  now  in  the  operational  controller  mode. 

To  transmit,  a command  word  is  enabled  onto  the  I/O  bus  and 
the  "Load  CMD  word"  input  is  strobed.  BIU  #1  decodes  the 
type  of  command  loaded  and  executes  it  as  such;  i.e..  Transmit, 
Receive,  Mode  (with  or  without  data  word) , Broadcast,  RT-RT. 

If  data  transfers  to  or  from  the  host  are  required,  then 
BIU  #1  will  activate  the  appropriate  DMA  control  lines  to 
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BIU  #1  BASIC  BLOCK  DIAGRAM 
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BIU  #1  FUNCTIONAL  PINOUT 
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perform  the  necessary  function.  Any  DMA  or  Message  related 
errors  on  the  data  received  in  reply  to  a command  are 
recorded  and  made  available  to  the  host  via  the  Control 
Word/Code  Execute  Strobe  method  discussed  previously.  An 
indication  of  an  error  condition  is  given  by  the  discrete 
output  "Error  Present".  A message  in  process  may  be  aborted 
by  the  same  control  word/code  execute  strobe  method  above. 

1.2.2  Initialization  of  BIU  #1  to  operate  in  the 
remote  mode  is  accomplished  as  in  Paragraph  1.2.1.  Once  in 
this  configuration/  BIU  #1  will  answer  any  command  addressed 
to  it  with  either  a normal  mode  command/response  or  a busy 
status  depending  on  the  logic  state  of  the  "Busy/Disable" 
input.  In  the  normal  mode,  BIU  #1  as  a remote  will  decode 
all  commands  addressed  to  it.  The  commands  decoded,  data 
transfers,  and  error  checking  is  performed  by  BIU  #1  as 
described  in  Paragraph  1.2.1. 

1.2.3  In  an  overview,  BIU  #1  may  be  used  as  a controller 
or  remote  and  will  perform  all  the  DMA  and  error  checking 
function  related  to  the  transfers  being  executed  when  used 
as  a stand-alone  device.  Figures  1.2. 3-1  and  1.2. 3-2  show 
two  simplified  connections  of  BIU  #1  in  a stand-alone  appli- 
cation. 

1.3  BIU  #2,  as  was  mentioned  above,  enhances  BIU  #1. 
BIU  #2  provides  an  additional  capability  in  order  for  the 
two  chip  sets  to  execute: 

1)  instruction  fetch  and  decode, 

2)  data  buffer  address  generation, 

3)  message  data  handling, 

4)  tag  word  generation, 

5)  mode  command  execution,  and 

6)  interrupt  generation. 

The  basic  block  diagram  of  BIU  #2  is  shown  in  Figure  1.3-1. 

A functional  pin  out  diagram  of  BIU  #2  is  shown  in  Figure 


1.3-2. 

1.3.1 

Five 

major  items  are  covered  in  this 

section : 

1) 

data  buffer  structure 

2) 

fetch  cycle 

3) 

command  word  generation 

4) 

data  buffer  address  generation. 

and 

5) 

time  tag  word  generation. 
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The  BIU  assumes  all  message  data  is  packed  in 
data  buffers  accessed  indirectly  through  pointer  blocks. 

Each  buffer  contains  N+1  addresses  so  a data  buffer  can 
hold  a tag  word  in  the  first  location  with  the  N message 
words  following.  At  initialization  the  Bill  is  given  data 
for  its  Instruction  Address  Register  (lAR)  which  points  the 
BIU  to  its  stored  program  instructions.  Instructions  there 
are  arranged  in  pairs;  the  format  is  given  in  Figure  1.3. 1-1. 
The  BIU  is  also  given  a Base  Address  Register  (BAR)  word;  and 
a Processor  Control  Word  (PCR) . In  a fetch  sequence  the 
lAR  contents  are  placed  on  the  I/O  Bus  and  loaded  into  an 
address  register.  The  first  instruction  word  is  acquired 
via  DMA.  The  incremented  values  of  the  lAR  is  again  loaded 
into  the  address  register  and  the  second  instruction  word 
is  acquired  via  DMA.  (The  lAR  is  incremented  again  internally 
to  prepare  for  the  next  fetch) . 

Once  tlie  two  instruction  words  are  acquired, 

BIU  #2  can  construct  the  command  words.  Referring  to  Figure 
1.3. 1-1  BIU  #2  compares  its  terminal  address  (available 
from  the  control  word  (PCR  word)  given  to  it  when  setup  by 
the  host)  with  the  device  address  in  the  instruction  words. 

If  BIU  #2's  address  is  the  same  as  the  Receive- Device  Address, 
then  the  command  to  be  generated  is  a transmit  command  to  an 
RT.  If  BIU  #2*s  address  is  the  same  as  the  Transmit-IWice 
Address,  then  the  command  to  be  generated  is  a receive  command 
to  an  RT.  If  BIU  #2's  address  does  not  compare  witli  either 
device  address,  then  an  RT-to-RT  pair  of  commands  is  to  be 
generated.  As  part  of  BIU,  BIU  #2  checks  to  assure  the 
Receive-Device  Address  is  different  from  the  Transmit-l^evice 
Address.  (An  interrupt  condition  is  set  when  the  two  are  the 
same)  . 


When  an  RT-to-RT  set  of  command  words  is  formed, 
no  data  buffer  address  is  generated  since  the  controller 
does  not  transfer  data  in  that  case.  When  an  RT-Receive  of 
RT-Transmit  command  is  generated,  BIU  #2  generates  a corres- 
ponding data  buffer  address.  As  mentioned  abov’e,  BIU  #2 
is  given  a Base  Address  Register  (BAR)  word.  BIU  #2  appends 
6 bits  (the  T/R  bit  and  subaddress  bits)  of  the  con\n\and  word 
to  the  LS  end  of  the  BAR  word  to  form  an  address  into  a 
pointer  table.  The  pointer,  acquired  from  the  table,  points 
to  the  first  address  in  the  data  buffer.  This  first  address 
is  reserved  and  the  pointer  to  it  is  stored  in  the  Pointer 
Register  of  BIU  #2.  The  incremented  value  (pointing  to  the 
second  addr?ss  of  the  data  buffer)  is  then  loaded  into  the 
external  address  register — ready  for  use  by  BIU  #1  when  it 
executes  its  DMA  transfers.  Once  the  data  buffer  address 
is  set  up,  BIU  12  is  ready  to  transmit.  From  that  point. 
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SQf, 


POINTERS  TO  64  MESSAGE 
DATA  BUFFERS 


> RECEIVE-MESSAGE 

POINTERS 

< 

s. 

> TRANSMIT-MESSAGE 

POINTERS 

TYPICAL  POINTER  BLOCK  USED  BY  BIU 


a 


1st  Address  in  Data  » 

Buffer  (contains  tag  wordy 

/ 

> 


MESSAGE  WORDS 


FIGURE  1.3. 1-2 
TYPICAL  MESSAGE-DATA  BUFFER 
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• BIU  12  DMA's  pointer  from  pointer  table;  pointer 

is  the  location  of  the  first  address  in  the  data  buffer 


• Pointer  is  stored  in  BID  #2's  Pointer  Register 


\h 

li 


• BIU  #2  loads  incremented  value  of  pointer  into  external 
address  register 

• BIU  #2  transfers  command  word  to  BIU  #1 

• BIU  #1  handles  data  DMA's 

• In  the  case  of  a 
DMA  by  BIU  #1  is 

word  into  the  first  address  of  the  data  buffer.  The  tag  !] 

word  transferred  contains  the  minor  cycle  number,  word  j) 

count  cuid  the  data  error  bit: 

____  WB  1^ 

MINOR  CYCLE  NO.  SPARE  WORD  COUNT  DE  H 

( bits) (2  bits)  ^(5_ijits)  _ 


RT-Transmit  message,  the  final  data 
followed  by  a DMA  by  BIU  #2  of  the  tag 


FIGURE  1.3. 1-3 

SUMMARY  OF  MASTER  CONTROLLER  BIU  MESSAGE  PROCESSING 


598 
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BIL;  #1  handles  the  DMA  data  transfers.  If  tlie  message  is 
an  RT-Receive  n\essa*.7e,  the  data  transfers  by  BID  #1  complete 
the  message  process.  However,  if  the  message  is  an  RT  - 
Transmit  message,  the  data  transfers  by  BID  #1  are  followed 
by  a final  DMA  transfer  by  BID  »2  of  the  tag  word  into  the 
first  address  of  the  data  buffer. 

The  discussion  above  assumed  the  RID  configured 
as  a master  controller.  In  the  remote  mode,  conuivand  genera- 
tion doesn't  apply.  However,  buffer  address  generation  does, 
and  is  as  above  except  the  con\mand  word  vised  is  that  receivevi 
from  the  manchester  bus. 

1.3.2  As  mentionevi  above,  the  BID  sets  interrupts  v^n 

various  conditions,  including: 

1)  message  errors, 

2)  status  word  except  iV'ns  , 

3)  certain  mode  commands,  and 

4)  program  requirements. 

Interrupt  generation  reflects  c>ne  of  several  facts: 

1)  The  BID  has  encountered  data  transfer 
problem  and  error  invlications  cannot  be 
overcome  without  host  intervention,  or 

2)  The  BID  has  been  initializevl  because  of 
a power  dropout  or  startup  and  neevls  tv'' 
be  set  up  by  the  host,  or 

3)  The  BID  has  finished  the  bus  orientv'vi 
tasks  revjuired  of  it  by  the  BID  program 
in  host  memory  and  the  program  revjuires 
host  notification,  or, 

4)  The  host  decides  to  intervene  in  BID 
operation  anvi  commanvls  the  BID  to 
gracefully  halt  operation. 

As  the  worvi  itself  invlicates,  an  interrupt  is 
a break  in  an  on-going  operational  screnario,  and  when  such 
a break  occurs,  reasons  for  interrupt  generation  ai'e 
recorded  by  the  DID  in  BID  #2's  Internal  Status  Register  (ISR) 
and  Bit  Register  (BIT) . Both  of  these  are  available  to  the 
BID  host,  anvi  BIT  in  a remote  controller  is  available  to  the 
master  controller  via  the  manchester  bus  by  use  of  a mode 
command . 


These  interrupts  can  be  viewed  from  two  per- 
spectives, that  of  the  master  controller  anvi  the  remote 
controller.  These  aspects  are  coverevi  below. 


I 

I 

I 


I 

tr 


M 


SgQ 


BIU  #1  receives  an  RT-Trcuismit  or  an  RT- Receive  command. 

BIU  #1  signals  to  BIU  #2  that  a command  word  is  present 
and  passes  the  command  word  to  BIU  #2  via  the  I/O  lines. 

BIU  #2  determines  the  command  is  an  RT-Transmit  or  an 
RT-Receive  command  and  begins  data  buffer  address  generation. 

BIU  #2  appends  the  T/R  and  subaddress  bits  of  the  command 
word  to  the  LS  end  of  a 10-bit  base  address  to  form  a 
16-bit  address  into  a pointer  table. 

BIU  #2  DMA’s  pointer  from  pointer  table;  pointer  is 
the  location  of  the  first  address  in  the  data  buffer. 

Pointer  is  stored  in  BIU  #2's  Pointer  Register. 

BIU  #2  loads  incremented  value  of  pointer  into  external 
address  register. 

BIU  #1  hcindles  data  DMA's. 

In  the  case  of  an  RT-Receive  message,  the  final  data 
DMA  by  BIA  #1  is  followed  by  a DMA  by  BIU  #2  of  the  tag 
word  into  the  first  address  of  the  data  buffer. 


FIGURE  1.3.  1-4 

SUMMARY  OF  REMOTE  CONTROLLER  BIU  MESSAGE  PROCESSING 


1.3. 2.1  Considering  the  BIU  as  a master  controller, 
interrupts  are  generated  and  actior  is  stopped  when  various 
conditions  exist.  These  conditions  may  be  of  such  nature 
that  would  be  corrected  by  additional  message  communication 
attempts  by  use  of  the  automatic  re-try  capability  of  the  BIU. 
This  tends  to  separate  hard  and  soft  failures.  Interrupt 
conditions  that  occur  which  would  not  allow  a re-try  are 

as  follows: 

1)  DMA  transfer  handshake  failure 

2)  Power-on-Reset  condition 

3)  Instruction  Halt  (from  Fetch  Sequence) 

4)  Specified  status  word  bits 

5)  Invalid  instruction  set  (from  Fetch 
Sequence) 

6)  Abort  (from  Host) 

Other  conditions  for  interrupts  which  would  allow  a re-try 
attempt  are  as  follows;  Re-try  Count  = 0 and, 

1)  Message  error  (transferred  from  BIU  #1) 

2)  Specified  status  word  bits 

Finally,  the  last  conditions  for  interrupts  are  conditions 
sensed  during  a normal  message  providing  none  of  the  above 
occurred.  These  conditions  are  as  follows: 

1)  Program  Controlled  Interrupt  (from 
Fetch  Sequence) 

2)  Mode  Data  Present  (BIU  receiving 
mode  command  data) 

3)  Halt  Command  (from  Host) 

4)  Asynchronous  Message  (Command  Address  = 30) 

1.3. 2. 2 When  the  BIU  is  operating  in  the  remote  mode, 
interrupts  are  generated  for  similar  conditions  as  before. 

In  this  mode,  interrupts  are  generated  and  action  is  stopped 
when  any  of  the  following  conditions  occur: 

1)  DMA  Transfer  handshake  failure  (BIU  #1) 

2)  Power-on-Reset 

3)  Asynchronous  Message  (Command  Address  = 30) 

4)  Synchronized  Mode  Command 

5)  Mode  Data  Present  (received  Mode  Command 
Data) 

6)  Master  Function  (BIU  receives  Mode  Command 
10001) 

The  BIU  will  remain  inoperative  until  serviced  by  the  host. 


A. 


ERROR  INTERRUPTS 
NO  RE-TRY  ALLOWED 


1)  DMA  transfer  handshake  failure 

2)  Power-on-Reset  condition 

3)  Instruction  Halt  (from  Fetch  Sequence) 

4)  Specified  status  word  bits 

5)  Invalid  instruction  set  (from  Fetch  Sequence) 

6)  Abort  (from  Host) 

B.  ERROR  INTERRUPTS 

RE-TRY  ATTEMPTS  ALLOWED 


Re- Try  Count  = 0 and, 

1)  Message  error  (transferred  from  BIU  #1) 

2)  Specified  status  word  bits 

C.  SYSTEM  INTERRUPTS 

1)  Program  Controlled  Interrupt  (from  Fetch 
Sequence) 

2)  Mode  Data  Present  (BIU  receiving  mode 
command  data) 

3)  Halt  Command  (from  Host) 

4)  Asynchronous  Message  (Command  Address  = 30) 


FIGURE  1.3.2. 1-1 

BIU  INTERRUPTS  IN  CONTROLLER  MODE 
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ERROR  INTERRUPTS 

1)  DMA  Transf»»r  handshake  failure  (BIU  #1) 

2)  Power  on  Reset 


SYSTEM  INTERRUPTS 

1)  Asynchronous  Message  (command  address  = 30) 

2)  Synchronize  Mode  Command 

3)  Mode  Data  Present  (received  Mode  Command  Data) 

^^"‘^tion  (BIU  receives  Mode  Command 


FIGURE  1.3. 2. 2-1 
BIU  INTERRUPTS  IN  REMOTE  MODE 
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1.3.3  When  an  interrupt  is  generated  by  the  DIM, 

BIU  #2  signals  the  host  via  its  Interrupt  Request  line  that 
the  BIU  needs  service.  Just  before  requesting  service,  BIU  #2 
sets  the  Busy/Continue  bit  in  its  Processor  Control  Register 
(PCR)  and  in  BIU  #l's  Status  Register.  After  generating  the 
request,  BIU  #2  monitors  the  Busy  bit  waiting  for  a change 
of  condition. 


In  a remote  controller  BIU  any  command  sent  to 
it  is  implemented  by  simply  returning  the  status  word  with 
the  busy  bit  set;  no  DMA  activity  occurs. 

In  either  controller  BIU,  the  activity  allowed 
during  the  busy  condition  consists  of; 

1)  monitoring  the  GO  and  Busy  bits,  and 

2)  implementing  the  control  codes  required 
by  the  host  of  BIU  #2. 

The  control  codes  available  to  the  host  are: 


0000 

Load 

Mode  Data  Register 

0001 

Load 

Master  Function  Register 

0010 

Load 

Instruction  Address  Register 

0011 

Load 

Base  Address  Register 

0100 

Load 

Processor  Control  Word 

0101 

Load 

Status  Word  Data 

0110 

Load 

Built-In-Test  Register 

0111 

Abort  Command 

1000 

Output 

Mode  Data  Register 

1001 

Output 

RCV  Status  Word/MFR 

1010 

Output 

Instruction  Address  Register 

1011 

Output 

Base  Address  Register 

1100 

Output 

Processor  Control  Register 

1101 

Output 

Internal  Status  Registor 

1110 

Output 

Built-In-Test  Register 

1111 

Halt  Conunand 

These  codes  give  the  host  control  of  the  BIU 
during  control-code  initiated  or  power-up  or  power-dropout 
initiated  busy  states. 


When  DIU  #2  initiali^es  itself,  it  sets  the  POR 
bit  in  BIT  word.  It  then  clears  the  ISR  and  other  bits  in 
BIT  and  sets  the  Busy  and  No-Go  bits  of  the  PCR  to  busy 
(0)  and  No-Go  (0).  Finally,  it  flags  its  condition  by 
setting  its  interrupt  line  active.  While  in  the  initialized 
state,  BIU  #2*3  registers  may  be  read  or  written.  The  PCR 
is  somewhat  special.  When  loading  the  PCR,  both  BIU  # 1 
cmd  BIU  #2  accept  data  from  their  respective  I/O  ports. 

The  control  code.  Load  PCR,  sent  BIU  #2  together  with  the 
control  code  strobe  causes  BIU  #2  to  generate  a code-execute 
strobe  to  BIU  #1.  Then,  both  BIU's  load  their  respective  PCR's 
If  the  Processor  Control  Word  from  the  host  has  Busy  and  No-Go 
bits  set  to  busy  and  no-go,  previous  state,  BIU  #1  will  now 
respond  to  all  valid  commands  with  the  status  word  showing 
the  busy  status  bit  set.  To  properly  enter  the  BIU  into 
an  operational  screnario,  BIU  #2's  BAR,  lAR  and  MFR  should  be 
loaded;  then  the  PCR  of  both  BIU  #1  and  #2  should  be  loaded. 

To  remove  the  BIU  from  the  active  state  to  the  busy  state, 
control  code  1111  (halt  gracefully)  should  be  sent  to  BIU  #2. 
BIU  #2  will  complete  message  processing  if  a message  is  present 
set  the  BIU  into  the  busy  state,  and  then  interrupt  the  host. 

At  this  point  any  of  the  registers  of  interest  can  be  read 
and  reloaded  if  necessary.  Finally,  PCR's  should  be  loaded 
to  re-enter  active  operation. 

1.4  In  sumniary,  the  BIU  chip  set  performs  the  functions 

required  by  MIL-STD- 155 3B , such  as  Mode  Code  execution,  RT  RT 
transfers,  broadcast  operation,  and  status  word  formats, 
in  addition  to  the  host  interface  action  described  herein. 
Figure  1.4-1  shows  a typical  chip-set  connection  diagram. 


Invalid  Cointnand 


1 


3 


6 


10 


LSB 

16 


a 

pi 

»-• 

p- 

S’ 

o 

1 

0 

(t 

ft 

< 

ft 

< 

CO 

w 

(n 

cn 

ft 

ft 

ft 

ft 

(U 

01 

0> 

01 

ft 

ft 

ft 

rf 

c 

0 

0 

0 

(0 

m 

u 

a 

w 

n 

w 

w 

X 

X 

p 

p 

o 

a 

p 

p 

(0 

(D 

0 

0 

•0 

*0 

p 

p 

ft 

p- 

ft 

p- 

O O (0  0) 

3 3 ft  ft 

0) 

ff  ft 


o 

W 

w 

z 

ft 

X 

X 

0 

0 

fcr 

ft 

ft 

P 

<0 

(0 

ID 

2? 

a 

p 

p 

P 

S 

3 

3 

(a 

n 

w 

p) 

Ot 

*0 

0 

0 

P* 

H 

0 

0 

(0 

3 

3 

o> 

ft 

H 

(0 

ID 

(D 

3 

a 

a 

0 

a 

B 

p- 

•3 

P- 

p- 

vQ 

(D 

3 

3 

3" 

P 

0> 

Ot 

PI 

M 

P* 

ft 

P- 

PJ 

PJ 

< 

01 

01 

(D 

p- 

p- 

M ls> 


5 

P 

•3  H 

01  9 

P < 

PJ 

2 

1 

O. 

p.  p) 

(D 

ft  P* 

P 

n 

s* 

g 

t<  p. 

a 

w 

1 

§ 

p 

p 

0 

3 

ft 

p as 

3 § 

1 

S’ 

p 

tr* 

P o 

n 

0 

3* 

(D 

(D 

CO 

ft 

(D 

P 

ft 

0 

0 

•3  < 

•3 

c 

P H 

p H 

01  0 

Ot 

o 

\ 

P P 

P 

p 

p.  d 
ft 

p.  d 
ft 

3 

3 

p:  a 

p; 

3* 

Ot  a 

p a 

o> 

Ot 

§ (D 

9 (D 

o W 

0 

10 

p-  p 

p-  P 

p 

p 

o <J 

o < 

9 

p- 

p- 

Ot  S 

Ot 

g 

a o 

a o 

o.  3 

0< 

3 

0 (D 

3 (D 

Oi  O 

(X  n 

u 

(0 

P 3- 

p 

a 

2? 

(D  (D 

<D 

(D 

O fit 

n Id 

in  in 

10 

(0 

0 aa 

0 a} 

(0  ft 

in 

ft 

3 c 

3 0 

(D 

(D 

ft  (D 

ft  (D 

(D  P 

(D 

p 

P CO 

P 0) 

p ' 

p 

% 

0 ft 

0 ft 

p 

p 

M- 

pt' 

0 

0 

P 

p 

> a 

> a 

O 0 

o & 

o & 

(D  (0 

(D  u 

*3  << 

»3 

ft  « 

ft  (0 

ft 

ft 

a (D 

a (D 

P-  9 

p-  9 

rf 

ft 

N a 

II  a 

M 0 

a 

(0 

*< 

FIGURE  1.3.  2-1 
BIT  WORD  FORMAT 
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Invalid  Instruction  (Master)  or  System  Interrupt  (Remote) 
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INTERNAL  STATUS  REGISTER  (ISR) 
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SOME  APPLICATIONS  OF  THE  ROCKWELL  DATA  TERMINAL  CHIP 

B.  E.  Bona 

Autonetics  Strategic  Systems 
Anaheim,  California 


1 . INTRODUCTION 


The  Data  Terminal  (OT)  chip  Is  a radiation  hardened,  micro-progranmable 
device  designed  for  use  in  Manchester  encoded  serial  data  buses.  This  paper 
briefly  describes  the  chip  functions  and  gives  some  typical  examples  of  its  use. 
The  examples  Include  a MIL-STD  1553A  interface  to  a doppler  velocity  system, 
application  In  a round-robin  bus  structure  where  the  broadcast  mode  is  used, 
and  In  complex  dual  redundant  bus  whose  protocol  is  similar  to  MIL-STD  155JA, 
but  with  longer  word  length  (I.e.,  B-1). 


2.  DATA  TERMINAL  FUNCTIONS 


The  OT  chip  is  a large  scale  integrated  CMOS/SOS  circuit^*)  designed  to 
perform  the  logic  and  digital  functions  required  to  mechanize  a Manchester  encoded 
time  division  multiplexing  system,  as  described,  for  example,  in  MIL-STD  1553A. 

The  OT  circuit  can  be  used  in  either  the  remote  terminal  or  controller  modes. 

The  DT  circuit  was  designed  to  meet  the  requirements  of  MIL-STD  1553A  and,  there- 
fore, utilizes  the  fixed  synchronizing  patterns  defined  therein.  The  OT  circuit, 
however,  is  prograinrable  so  that  variations  on  word  length  (e.g.  B-1  and  Space 
Shuttle),  field  definition,  and  bus  protocol  can  be  accommodated  with  appro- 
priately programmed  external  ROM(s).  A brief  summary  of  the  functions  provided 
by  the  DT  circuit  is  as  follows: 

(1)  Manchester  encode  and  decode. 

(2)  Sync  detection  (Receive)  and  Sync  generation  (Transmit). 

(3)  Terminal  address  compare. 

(4)  Output  and  input  NR2  in  sync  with  data  clock. 

(5)  Store  and  output  word  count 

(6)  Check  parity  (Receive)  and  generate  parity  (Transmit). 

(7)  Error  detection:  valid  Manchester;  word  length;  parity; 
message  length. 

(8)  Assemble  and  transmit  status  and  data  words.  (Includes 
sync  signals  and  parity). 
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Redundant  Data  Bus  Circuit 


3.  APPLICATION  IN  DOPPLER  VELOCITY  SYSTEM 


3.1  General  Description 

Figure  1 shows  a generic  example  of  how  the  DT  circuit  might  be  used  in 
a single  channel  MIL-STD-1553A  bus.  In  the  following  example,  the  DT  circuit  is 
used  in  a dual  redundant  1553A  bus.  The  application  is  for  a doppler  velocity  ' 
system  (DVS).  The  comnunication  is  rather  simple:  each  time  a transmit  command 
is  received,  the  DVS  responds  with  three  data  words.  The  complete  message  is 
shown  in  Figure  2. 


Figure  1.  Remote  Terminal/Controller  Configuration 
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COMMAND  VNWO 


STATUIWORD 


V^WORO 


VqWORO 


Vy  WORD 


TJ" 


C02 

COS 

WCO 

WC1 

V|,INN 

V^INN 

Vy  INN 


Figure  2.  Timing  for  Data  Transfer 


The  dual  redundant  MIL-STO  1553A  data  bus  circuit  (DBC)  used  to  interface 
with  the  DVS  is  shown  in  Figure  3.  The  circuit  consists  of  two  independent  bus 
channels.  Each  of  these  channels  is  configured  with  a T/R  hybrid  unit  and  with 
a data  terminal  device  along  with  its  associated  ROM(s),  as  shown  in  Figure  3. 

Outputs  of  two  primary  channels  are  cross-coupled  in  such  a way  that  the 
channel  receiving  the  most  recent  comtiand  takes  precedence.  The  interface  from 
the  DBC  to  the  DVS  is  bit-serial  over  the  bi-directional  data  line  DATTT,  at  a 
clock  rate  of  1 MHz.  Clock  (CACT),  control  (CO’s),  word  count  (WC),  message 
error  (ME),  early  warning  (B),  and  busy  lines  are  also  used  to  interface  the  DBC 
with  the  DVS. 
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Word  and  Message  Control 


The  data  terminal  device  performs  the  Manchester  coding  and  decoding,  data 
validation  checks,  and  other  functions  required  to  conform  to  MIL-STD  1553A 
requirements.  For  the  DVS,  the  DT  circuit  is  programmed  to  receive  the  Transmit 
conmand  word  and  to  determine  if  the  command  is  directed  to  the  DVS  tenninal 
(compare  terminal  address).  If  the  command  is  for  the  DVS.  the  B line  is  set  low 
for  two  bit  times  and  is  used  to  alert  the  DVS  of  the  impending  requirement  to 
transmit.  In  the  DT  program  for  this  application,  none  of  the  conmand  word  bits 
are  transmitted  to  the  DVS  over  the  serial  line  (DATTTK  The  DT  checks  the  parity 
bit  of  the  conmand  word  and  sets  the  ME  flip-flop  if  an  error  occurs.  This  error 
signal  is  sent  to  the  DVS,  indicating  an  error  in  the  conmand  word.  The  DT  pro- 
gram has  a halt-on-message  error  instruction  which  prevents  the  DT  from  branching 
to  the  transmit  status  routine,  if  an  error  (invalid  Manchester  word  length  or 
parity)  is  detected  in  the  conmand  word. 

If  there  is  no  message  error,  the  DT  branches  to  the  transmit  status 
routine.  The  DT  transmits  the  status  sync,  the  terminal  address,  the  ME  bit, 
and  sets  control  C02  causing  the  ten  data  status  bits  to  be  serially  transmitted 
over  line  DATTT,  from  the  DVS  to  the  DBC.  The  DT  then  adds  the  appropriate 
parity  bit. 

After  transmitting  the  status  word,  the  DT  branches  to  the  transmit  data 
routine  where  it  proceeds  to  transmit  the  three  data  words,  after  which  it  halts. 
Word  count  lines  WCO  and  WCl  and  control  line  COS  are  used  to  strobe  the  velocity 
data  from  holding  registers  located  in  the  DVS.  Figure  2 shows  the  basic  timing 
associated  with  the  data  transfer.  Figure  4 shows  some  typical  interface  logic 
that  might  be  implemented  in  the  DVS.  The  signals  Vyinh,  Vjinh  and  Vj^inh  are 
used  to  load  data  into  the  registers.  Loading  is  accomplished  when  these  signals 
are  high;  data  is  serially  transferred  when  they  are  low. 

3.3  Channel  Control 

The  channel  that  interfaces  with  the  DVS  system  is  controlled  by  the  com- 
bination of  a channel  select  flip-flop  and  a multiplexer.  When  a channel  detects 
a conmand  sync,  it  sets  the  DT  program  counter  to  the  location  hex  80.  If  the 
terminal  addresses  compare,  the  B flip-flop  is  set  to  the  T/R  bit  (T/R  = 1 for  DVS), 
and  remains  set  for  two  bit  times.  This  signal  sets/resets  the  channel  select 
flip-flop  which  in  turn  couples  the  appropriate  DT  outputs  to  the  DVS  via  the  two 
54157  multiplexers.  The  signal  is  also  used  to  halt  the  other  DT  via  the  external 
interrupt  line. 

3.4  DVS  Program  Description 

Flow  charts  and  program  listings  for  the  transmit  conmand,  status,  and 
transmit  data  routines  are  shown  in  Tables  1 through  3 and  Figures  5 through  .. 
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Typical  DVS  Interface  Logic 
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Table  1.  Transmit  Command  Program 

Transmit 


- 

■■■■ 

Conmand  Sync  Interrupt 

80 

81 

82 

BNTA  0 > 

Branch  if  the  incoming  data  is  not  a command 
for  this  terminal 

83 

BNTA  0 1 

84 

BNTA  0 ) 

85 

HB 

86 

FLG  F 

87 

RB 

Reset  B 

88 

FLG  F 

89 

FLG  F 

8A 

FLG  F 

88 

LDWC  \ 

8C 

FLG  F 1 

8D 

FLG  F > 

Load  data  word  count 

8E 

FLG  F 1 

8F 

LDWC  ) 

90 

PTY  0 

Check  parity;  Set  CO's  to  end  receive  command. 

91 

FLG  F 

Begin  gap  for  status  word 

92 

HME 

Suppress  transmission  if  error  on  command 
reception 

93 

BR  A 

Branch  to  Transmit  Status  Routine  (Loc  AO) 

01 

HLT\ 

02 

HLT  J 

Entry  Points  from  80-84 

03 

HLT  \ 

Halt  if  the  incoming  data  is  not  a command  for 

04 

HLT  ( 

this  terminal 

05 

HLT  j 

i 
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Table  2.  Transmit  Status  Routine 


lA 

I 

Transmit  Status 

AO 

A1 

THl  0 ) 

TONE  J 

Transmit  a command/ status  sync;  set  CD's  for 
begin  transmit  status 

■ 

TLO  0 ) 

TTA 

A4 

FLG  F ) 

A5 

FLG  F > 

Transmit  the  address  of  this  terminal 

A6 

FLG  F ) 

A7 

TTA 

AS 

THE  0 

Transmit  ME;  do  not  Change  CO's 

AS 

FLG  F ' 

• 

• 

B1 

: 

FLG  F 1 

. 

Input  and  transmit  status  codes 

B2 

FLG  F J 

B3 

PTY  0 

Transmit  parity,  reset  CO's 

B4 

[1st 

Instruction  of 
Transmit  Data] 

Begin  Transmit  data  routine  at  this  point;  no 
branch  permitted. 

imm  ♦ • 

TT“ 


mmmi 


Figure  5.  Transmit  Command  Flow  Chart 
M7 


Table  3.  Transmit  Data  Routine 


lA 

I 

Transmit  Data 

B4i6 

TLO  0 j 

85 

TZRO  ! 

Transmit  data  sync  and  set  CD's  for  begin  transmit 
data 

B6 

THI  8 ) 

87 

FLG  F \ 

• 

Input  and  transmit 

CO 

Branch  in  EC  entry  Point  first  14  bits  of 

; 

■HI 

data  word 

C4 

1 

FLG  F ' 

C5 

DOWC 

Decrement  the  data  word  count 

C6 

BCNZ  E 

Branch  if  this  is  not  the  last  data  word 

C7 

PYT  0 

Transmit  parity;  reset  CO's 

C8 

HLT 

Halt;  operation  complete 

EO 

PTY  0 

Entry  point  for  branch  in  C6;  transmit  parity; 
reset  CO's. 

El 

TLO  0 ) 

E2 

TZRO  [■ 

Transmit  data  sync  for  next  data  word;  set  CO's 
for  begin  transmit  data 

THI  8 ) 

E4 

FLG  F ) 

1 

. ( 

Input  and  transmit  first  part  of  next  data  word 

EB 

FLG  F ) 

EC 

BR  C 

J 

Branch  into  corresponding  point  of  original 
transmit  data  sequence  (above) 
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4,  ROUND-ROBIN/BROADCAST  FUNCTIONS 


In  systems  that  employ  broadcast  modes,  a remote  terminal  is  required 
to  respond  to  Its  own  unique  address,  In  addition  to  a broadcast  address.  In 
Round-Robin  systems,  a terminal  may  be  required  to  respond  to  some  of  all  of 
the  other  terminals  sending  messages(2).  The  DT  device  can  be  easily  progranmed 
to  satisfy  the  afeove  requirements.  If  a terminal  Is  required  to  respond  to  n 
addresses,  then  basically  n parallel  channels  are  needed.  Figure  8 shows  a 
program  with  three  channels.  If  the  terminal  address  for  Channel  1 Is  xxxxx, 
then  Channel  2 will  respond  to  terminal  address  xxxxxx  and  Channel  3 to  address 
xxxxx.  It  Is  Interesting  to  note  that  each  channel  can  be  programmed  to  process 
the  data  following  the  terminal  address  in  a unique  way.  This  feature  should  be 
extremely  useful  In  Round-Robin  systems,  where  each  channel  would  correspond  to 
a unique  transmitting  terminal.  Note,  however,  that  this  additional  versatility 
Is  accompanied  by  the  requirement  to  provide  a distinct  and  separate  ROM  program 
for  each  terminal. 


Figure  8.  DT  Flow  for  Multiple  Terminal  Addresses  (XXXXX,  XXXXX,  XXXXX) 
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In  MIL-STD  1553A  systems  with  one  broadcast  address  (e.g.,  11111),  It  is 
possible  to  have  one  ROM  program  for  up  to  sixteen  terminals.  Figure  9 shows  a 
program  that  utilizes  the  Branch  on  Data  (BRD)  Instruction  to  implement  the 
broadcast  mode  for  address  (11111),  where  the  sixteen  terminal  addresses  are  of 
the  form  (oxxxx). 


MTU  TV  MClIVt  MT*  (Rtr  1.  nt  • 

Figure  9.  Unique  Address  (oxxxx)  Channel  1 and  Broadcast 
Address  (11111)  Channel  2 


The  program  In  Figures  8 and  9 are  only  used  to  Illustrate  versatility 
of  the  DT  programming  features.  As  with  any  programmable  device,  there  are 
generally  numerous  programs  that  will  accomplish  the  same  objective.  Such  is 
the  case  with  the  DT  device. 
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B-1  MULT  I PLEX- INTERFACE -MOnULE 


The  DT  device  was  intended  for  use  in  the  B-1  EMUX  system  before  its 
demise.  The  B-1  protocol  was  similarly)  to  MIL-STD  1553A,  but  with  significant 
differences,  a few  of  which  include  a 24-bit  word  length,  no  terminal -to-terniinal 
mode,  and  four  leading  validity  bits  followed  by  16  bits  as  specified  in  1553A. 

The  multiplex-interface-module  (MIM)  had  dual  channels  with  unique  requirements 
for  defining  which  channel  was  active.  Without  listing  all  of  the  requirements, 
suffice  it  to  say  that  considerable  logic  was  required  to  check  for  valid  commands 
and  to  effect  channel  control. 

In  this  application  the  DT  program  counter  was  extended  to  accomplish 
much  of  the  channel  control.  To  do  this,  it  was  found  expedient  to  extend  the  DT 
program  counter  from  9 to  10  bits  using  the  lines  designed  for  this  purpose. 

Figure  10  shows  the  memory  addressing  used.  As  shown  an  Sk  ROM  (10  ^ 8)  was  used, 
with  a flip-flop  used  to  extend  the  addressing  capability  of  the  DT  to  10  bits. 

The  address  register  was  extended  in  the  lease  significant  direction  and  a binary 
point  was  used  to  specify  this  bit  position.  For  example,  location  hex  80  is 
extended  to  location  80.0. 


IITS-*-! 
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The  OT  requires  four  data  lines  from  the  ROM.  The  four  extra  data  lines 
from  the  8k  ROM  were  used  to  extend  the  basic  DT  Instruction  set.  As  Indicated 
In  Figure  10,  four  ROM  data  lines  are  directed  to  the  DT  and  the  other  four  are 
decoded  to  generate  the  additional  control  Instructions.  Normally  the  DT  uses 
one  instruction  per  bit  time,  but  with  the  extension  shown  in  Figure  10,  it  is 
possible  to  perform  two  instructions  per  bit  time.  In  the  B-1  application,  these 
extended  instructions  were  used  to  accomplish  channel  control,  load  external 
registers,  and  perform  assorted  other  logic  functions  in  synchronism  with  the 
NRZ  data  and  system  clock  (CACT). 


6.  SUMMARY 


This  paper  has  presented  some  application  of  the  DT  device.  As  seen 
from  the  discussion,  the  device  can  be  used  from  the  simplest  to  the  most  complex 
systOT  with  relative  ease  and  efficiency.  As  with  any  progranmable  device,  its 
use  is  limited  only  by  the  imagination  of  the  user. 
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A HYBRIDIZED  I 553A  INTERFACE 


W.  R.  Hunter 

Teledyne  Systems  Company 
Northridge,  California 


ABSTRACT 

This  report  describes  a 1 553A  interface  designed  to  enable  a Teledyne 
computer  to  function  as  Bus  Controller  and/or  Remote  Terminal  in  a dual- 
redundant  Multiplex  Data  Bus  system.  The  interface  complies  with  MIL- 
STD  1 553A  requirements  and  is  designed  to  connect  directly  to  most  general 
purpose  computers.  For  minimum  size  and  weight,  all  circuit  components 
are  in  dice  form  fabricated  in  hybrid  packages.  There  are  three  functionally 
unique  hybrids: 

• A Driver/Receiver  hybrid 

• Multiplex  Terminal  Unit  (MTU)  hybrid 

• A Device  Control  Unit  (DCU)  hybrid 

The  Driver /Receiver  hybrid  couples  directly  to  a dual  data  bus  system 
accommodating  TTL  control  and  data  signals  on  one  side  and  +10V  Manchester 
bi-phase  signals  on  the  bus  side.  The  MTU  provides  a full-duplex  serial 
interface  between  the  Driver /Receiver  and  DCU  hybrids.  MIU  functions 
include  code  conversion  between  NRZ  and  Manchester,  serial  timing  and 
formatting  for  input/output  data,  validity  checks  on  received  data,  and  a total 
message  length  monitor.  The  DCU  performs  all  message  handling  requirements 
of  a Bus  Controller  and/or  Remote  Terminal.  It  utilizes  the  computer's  main 
memory  for  working  storage  moving  data  in  and  out  via  Direct  Memory  Access 
(DMA). 

Computer  software  presides  over  DCU  Bus  Controller  operations,  Flach 
bus  transaction  is  initiated  by  outputting  a message  pointer  and  a control  word 
specifying  the  number  of  transmit/ receive  words.  As  a Remote  Terminal,  the 
program  specifies  RT  address  and  controls  10  bits  of  the  status  word.  Controller 
and  Remote  Te rminal  functions  are  assigned  separate  DMA  ports  thereby  enabling 
simultaneous  liC/RT  operation  for  lOO*’’,.  self-test  capability.  Other  design  fea- 
tures include: 

1.  Bus  Controller  memory  addressing  up  to  hSK:  separate  Remote 
Terminal  memory  addressing  of  2K. 

2.  A "next  message  queue"  for  continuous  Controller  operations. 

3.  Remote  terminal-to- remote  terminal  messages. 

A message  error  status  register  with  interrupt  and  an  automatic 
system  reset  on  excessive  message  length  times. 
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A doad-lnu'  discroto  mdicatin>;  i\o  Ixi.s  tr.Ut'u'. 

('•  A InUtor  to  hold  tho  last  rocotvod  conxn-.and  as  romoto  t«'rininal 
tor  projjraiu  uitor ronatiot\. 


IN  riU-tniU'  I RIX 

\Ul.-Sin  l-'Hi  ricidlv  doliiu's  tho  oomtmimoat  u>ns  protoool  and  data  struoturo 
tor  translorrtn>:  inforinatio.,  ovor  a tuno  ou.ltiploxod  hos.  This  results  ut  a lu>ih 
do>troe  ot  stauda rdt/.ation  tor  i.itortaom,!  diltoront  oquipmout  ivpos  as  nvoU  as  a 
cost  ottoctivo  moans  tor  mtorconnoctnij;  tuimorous  dispersed  subsystems.  Hesicn 
eomploxitv  of  each  interface  depends  on  the  suhs\  stem  heini;  interfaced  and  the 
perlormance  features  required  Lv  the  end-user.  In  any  desipn.  lunyever,  those 
ureas  itiost  are: 

Kehahle  extraction  of  data  off  the  hus 
I'redictahli'  recovers  from  .ill  error  situations 
Sottsv.ire  contri'l  s’ersus  dedu'.ited  lianiw.ire  solutions 
lUiilt-in  self  test 

iVsii:nin>;  for  the  eventualities  of  Mll.-Srp  1 

leledyne’s  lss3  Interface  is  desi>;ned  to  mate  with  most  ceneral  purpose 
computers  having;  direct  memory  access  (UMAl  and  programmed  1 v"*  capabilits 
I^MA  operations  are  In-hit  parallel  structured  around  popularly  used  core  memory 
tmnn^.  I'he  projjrammed  I/O  functions  utilize  a lo-hit  lu-directuMial  data  bus. 

Ihe  intertace  runs  primarily  off  computer  supplied  clock  for  synchronous  data 
exchan.ce  while  front-end  lo>;ic  requires  an  accurate  S MHz  clock  for  timim;  data 
sw  and  off  the  bus. 

I'  or  size  and  weight  considerations,  all  ciruit  components  are  in  .lice  form 
and  custom  fabricated  in  hybrid  packai;es.  A typical  hybrid  is  shown  in  Ih.mire  1 
As  shown  in  Ki>;ure  J.  the  l-^^d  hybrid  trio  consists  of  Pevice  Control  Cnit'dH'l  l’ 
Multiplex  lerminal  Hint  (MTH).  and  driver  Receiver.  With  these  elements,  a 
host  computer  can  operate  over  a dual  data  bus  configuration  as  Inis  c ontroller 

or  as  a Remote  lerminal  by  exercising  the  interface  controls  summarized  in 
Table  1 . 


dkvicf:  control  i'nit  (pcu) 

Ihe  IX'l’  performs  those  functions  required  of  a bus  controller  and  remote 
rerminal  as  specified  in  M 1 L-STO- 1 Ss3A  for  message  processing.  It  is 
re.sponsible  tor  all  message  contents  into  and  out  of  the  local  subsystem’s  own 
memory.  The  connected  subsystem  (computer  or  controUerl  directs  the  activities 
of  the  bus  controller  portion  of  the  HCU  by  sending  it  starting  addresses  of  the 
message  in  its  memory  and  the  number  of  words  (commands  and  datal  to  be  trans- 
mitted plus  the  number  of  words  to  be  received  (status  and  data).  The  remote 
terminal  portion  of  tho  DCU  operates  without  subsystem  intervention  other  than 
specifying  tho  remote  terminal's  address  and  10  least  significant  bits  of  .s  pA  TU.s. 


iilgl 


Figure  1.  Typical  Hybrid 


rioni'Si 


The  five  most  significant  bits  of  the  lb  bit  RT  DMA  address  select  a 2048  word 
block  assigned  to  buffer  messages  when  the  DCU  is  operating  as  a remote  terniinal. 
These  bits  are  available  on  external  pins.  The  DCU  described  below  and  showni  in 
Figure  3 will  operate  independently  and  simultaneously  as  bus  controller  and/or 
remote  terminal.  That  is,  the  bus  controller  can  talk  to  itself  as  though  it  were 
1 of  32  remote  terminals  providing  a 100'!'i'  closed-loop  self-test  capability. 

To  initiate  a message-on  the  bus,  the  local  subsystem  outputs  two  control 
words  to  the  DCU.  One  specifies  a starting  address  in  the  subsystem's  memory  and 
the  other  defines  the  number  of  words  involved.  These  control  word  formats  are: 


CONTROL 
WORD 
OUTPUT  1 


CONTROL 
WORD 
OUTPUT  2 


r 
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Table  1.  1553  Interface  Control 


I’rog  r.itnnud  l.  Outputs 

1 ’ rog  ra nimod  Inputs 

Inti'  rrupt  s 

Pi  s 0 ri't  I's 

Hf  Aticircss  I’umter 

IH'  Word  I'oiint  'Hus  St'loit 

K T Sta  tus  / Add  re  ss 

MSCl  •■'rror  Status 

K 1'  Comtn.ii'ai  s 

Hi'  'K  1 MSli  I'onipli'tf 

HC  /H  ]'  ,\1S( 1 r ror 

1\  I'  1 ommand  K o v 'd 

Hi’  Hus\ 

R 1 Jtus\ 

Hus  Ina  i 1 1 vo 

Inlulut  Hus  A 

Ininlut  Hus  H 

HC  - Hus  Controller 
K T = Konioto  Torniinal 


If  not  currently  busy,  the  DCU  will  itninediatelv  respond  to  output  coittrol 
word  2 by  fetching  (via  direct  memory  access)  the  first  command  word  of  the 
message  at  the  starting  location  specified  by  control  word  1 and  engage  the  M Tl’ 
by  raising  the  output  sequence  enable  lino.  The  svnc  tvpe  specified  will  be  a 
command  sync  since  the  first  word  of  each  controller  message  is  a command 
to  some  remote  terminal.  There  are  two  word  counters  in  the  nCl\  one  for 
transmit  and  one  for  receive  that  are  loaded  with  the  contents  of  control  word  2. 

The  transmit  word  counter  decrements  each  memorv  cvcle  until  it  readies  . ero 
whereupon  the  DCl'  mode  clianges  from  transmit  to  receive  and  subsequent  word 
inputs  from  the  M Tl'  are  written  contiguously  into  memory  starting  from  the  last  I 

output  word  location.  The  receive  mode  continues  until  the  receive  word  counter  i 

reaches  zero.  At  this  time  a message  complete  interrupt  is  issued.  The  DCT'  ^ 

tlien  determines  if  a new  pair  of  control  words  has  been  placed  in  queue  during  ! 

the  last  message.  If  so,  a new  message  commences.  If  not,  the  DCL'  goes  idle. 

Memory  allocation  for  bus  messages  is  very  flexible.  The  subsystem  pro-  f 

gram  may  designate  any  length  blocks  (0  to  63)  starting  anywhere  in  o5K  of  ^ 

memory.  Data  within  each  block  is  accessed  sequentially.  For  example,  bus  ^ 

controller  to  remote  terminal  message  block  would  contain  the  remote  terminal  [ 

receive  command,  followed  by  the  data,  followed  by  a location  reserved  for  1 

receiving  terminal  status.  The  transmit  word  count  would  include  the  comniand  | 

word  plus  the  number  of  data  words.  The  receive  word  count  wQuld  be  one  for  j 

tlie  status  reply.  The  word  count  in  the  output  control  word  thus  includes  all  * 

message  words  — commands,  data,  and  status.  The  b-bit  field  accommodates 
the  longest  possible  message  type  which  is  remote  terminal  to  remote  terminal. 

For  this  case  two  command  words  are  transmitted,  followed  by  a siatus  word 

and  up  to  32  data  words,  and  then  a second  status  word.  ^ 

, I 

The  total  message  length  tinie-out  error  logic  in  the  MTl’  can  be  checked  ,| 

by  specifying  excessive  words  in  the  transmit  or  receive  message  portion.  Two  ’ 

bits  of  control  word  2 specify  on  which  of  the  two  busses  the  controller  performs 
transactions;  Bus  A or  Bus  B,  both  A and  B,  or  none.  Bus  switcliing  times 
coincide  with  the  start  of  each  message  under  DCU  control. 
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lino  bit  in  control  word  2 is  dedicated  to  tlie  remote  terminal  to  remoie 
terminal  mode  of  operation.  I'lie  ni'U  uses  this  bit  to  cause  tlie  firsl  (wo  w.irds 
to  lie  output  witli  command  syncs. 

rhe  remote  terminal  (U  T)  portion  of  the  IH'U  operates  independent  ol  the  Inis 
controller  portion.  It  interlaces  to  the  subsystem  memori’  via  its  o\vn  UMA  pi>rl 
working  into  and  out  of  a 2048  word  block  specified  by  the  subsystem'.  It  recpiires 
no  program  control  Irom  tlie  subsystem  to  lunctiiin  except  for  liaving  its  program- 
mable 11)  register  loaded.  Ihe  program  also  has  access  to  the  10  LSlts  of  the  K I' 
st.atus  word. 


Serial  input  trom  the  M 1 11  is  constantly  monitored  lor  a ciimmaiul  wvini  having 
a remote  terminal  address  (ID)  matching  its  own.  Ihe  serially  received  hits  are 
converti'd  into  a In-bit  parallel  word  and  the  ION' P OP  WDRP  pulsi-  from  (he  M I'li 
la  used  as  the  time  to  examine  the  terminal  address  fiehl  (if  the  word  was  also 
preceded  bv  the  command  sync  signal).  If  a match  is  found,  the  logic  will  strobe 
the  wortl  count  field  of  the  command  word  into  a counter,  latch  the  suhaddn-ss 
field  of  the  command  along  with  Ihe  transmit /receive  ( I'/R)  bit.  load  the  entire 
li'-bit  command  into  a holding  register,  issue  a command  reci'ived  interrupt  to 
the  subsystem  and  post  the  R T busy  signal. 

Lf  other  than  a special  function  commaiul  (subadd vess  field  / 0).  tlu’  Pi'U 
takes  one  of  two  courses: 

If  fl'n  I'/R  bit  = 0.  the  IIC'U  will  accept  all  the  words  that  follow 
having  a data  sync  preface  and  store  them  sequentially  into  the 
memory  block  specified  b\  the  subaddress  field.  When  the  number 
of  memory  cycles  performed  matches  the  received  word  counI,  tlu' 

Pc  P plact's  its  status  word  out  on  the  bus  and  wlieii  transmitted, 
exercises  the  same  message  complete  inti'rrupl  usi'd  by  tlu-  bus 
controlle  r logic. 

2.  It  the  r/R  bit  = 1,  (he  PCI'  immediately  transiiiits  its  status  word 
followed  by  tlie  number  of  data  wonts  specified  in  the  wurd  count 
Held,  then  generates  the  message  complete  interrupt. 

Receipt  ol  a special  function  command  (subaddress  field  = 0)  with  tlu'  proper 
terminal  address  and  l /R  = 1 will  cause  the  PC'P  to  latch  the  command,  generate 
the  command  received  interrupt,  and  respond  with  status  only.  Xo  further  action 
is  taken  by  the  IX'P  and  no  busy  is  posted. 

The  R'l’  logic  can  be  redirected  mid-message  (if  receiving)  In  another  com- 
mand with  no  consequences.  I'he  PCD  will  ignore  all  received  commands  that 
have  detected  bit  or  parity  errors.  The  bus  command  that  elicits  remoli'  terminal 
response  is  held  until  a new  command  replaces  it.  Die  program  has  ample  time 
to  interrogate  the  command  register  by  eyecuting  tlie  proper  input  instruction. 

Only  data  words  are  transferred  to/from  memory  in  the  R 1'  mo<le.  C'ommands 
and  status  words  are  not.  In  an  Rl’-to-R  T transfer,  the  Pt'P  will  pick  out  its 

631 


command  ignoring  al)  others  and  properly  handle  the  data  and  status  word 
requirements  as  specified  in  MIL-STD-1  553A.  The  status  word  is  supplied 
by  hardware,  i.e.  , not  DMA'd  from  memory.  The  program,  however,  controls 
10  bits  of  the  status  for  whatever  future  systems  may  need.  The  MTU  supplies 
the  message  error  bit  and  the  terminal  ID  is  programmable. 

Memory  locations  for  remote  terminal  messages  are  normally  specified 
by  the  subaddress  field  in  the  received  command.  Up  to  sixty-two  32-word 
blocks  (2K)  can  be  addressed  using  the  T/R  bit  as  part  of  the  address.  A sub- 
address field  of  all  zeros  is  not  used  as  a working  RT  address  block  in  either 
transmit  or  receive.  A transmit  and  receive  command  with  the  same  subaddress 
fields  will  have  RT  memory  blocks  that  are  IK  apart.  The  data  v/ords  of  the 
message  will  be  fetched  or  stored  sequentially  starting  at  the  first  location  of 
the  block.  The  five  most  significant  bits  of  remote  terminal  DMA  address  are 
adjustable  via  hardwire  so  that  the  location  of  the  2K  RT  transmit/receive  memory 
block  can  be  positioned  as  system  needs  dictate. 

MULTIPLEX  TERMINAL  UNIT  (MTU) 

The  MTU  interfaces  the  DCU  to  the  bus  drivers  and  receivers  by  performing 
all  bit  and  word  serialization  on  data  to  and  from  the  bus.  It  accepts  Manchester 
encoded  data  from  the  line  receivers  and  outputs  NRZ  data  to  the  DCU.  Similarly 
it  takes  (on  command)  serial  NRZ  encoded  data  from  DCU  and  supplies  Manchester 
encoded  data  to  both  line  drivers.  Input  and  output  occurs  independently  and 
simultaneously,  thus  providing  a full  duplex  serial  interface  to  the  DCU.  The 
MTU  also  performs  bit  error  checking,  word  parity  checking,  and  a total  message 
length  time  check  as  indicated  in  the  block  diagram  of  Figure  4.  A dead-line  dis- 
crete is  also  provided  indicating  no  traffic  on  the  bus  for  a time  exceeding  65.  5 
milliseconds. 

The  MTU  constantly  monitors  for  bus  activity.  It  is  up  to  the  system's  bus 
controller  to  prevent  both  busses  being  active  at  one  time.  An  "active  bus" 
discrete  signal  is  sent  to  the  DCU  by  the  MTU  to  specify  which  bus  is  active  and 
providing  data.  This  signal  is  intended  for  operating  in  the  remote  terminal 
mode  so  that  any  reply  will  be  transmitted  back  on  the  active  bus.  If  the  DCU 
is  active  as  a bus  controller,  then  the  active  bus  is  specified  by  the  local  sub- 
system via  a control  word. 

The  TRUE  /TRUE  signals  from  each  receiver  are  sampled  with  an  8 MHz 
clock  in  to  a 24-bit  register  presenting  a 3 /is  snap-shot  of  incoming  signal 
patterns.  (A  front  end  "transition  stretcher"  helps  offset  differing  duty  cycle 
relationships  between  receiver  signals.)  Eighteen  bits  of  the  24-bit  serial 
register  are  selected  as  a sample  bit  pgittern  to  address  PROM  memory  coded 
for  Manchester  data  bit  recognition  and  1 553A  sync  pattern  recognition.  Recog- 
nition of  a commnd  or  data  sync  (at  any  time)  initializes  all  receiving  logic  and  the 
search  for  valid  data  bits  commences.  A window  is  generated  _f 2 50  ns  about  the 
theoritical  mid-point  of  each  data  bit  during  which  the  bit  recognition  outputs  of 
the  PROM  are  examined.  If  a valid  bit  pattern  is  detected,  the  window  re-syncs 
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and  the  bit  is  latched.  If  no  data  pattern  detection  occurs,  a bit  error  is  latched 
and  the  window  re-syncs  itself  and  attempts  to  find  the  mid-point  of  the  next  pre- 
dicted bit. 

Bit-by-bit  construction  of  every  incoming  word  proceeds  with  each  bit  being 
handed  off  to  the  DCU  with  a gated  clock  (1  clock  per  bit)  until  the  17th  parity  bit 
is  received.  Should  the  parity  bit  not  compare  with  the  accumulated  odd  parity 
over  the  previous  16  bits,  an  error  flag  is  set.  Parity  is  not  sent  to  the  DCU, 
however  an  end  of  word  pulse  is  transmitted.  Figures  5 and  6 illustrate  MTU 
receiver  timing  as  described  above. 

To  output  a word,  the  r5CU  raises  an  output  sequence  enable  signal  to  the 
MTU.  The  MTU  sends  load  and  clock  signals  back  to  the  DCU  and  pulls  the 
16-bit  data  word  bit  at  a time  for  output.  The  MTU  posts  a master  enable  to 
both  drivers  that  brackets  the  outbound  sync,  data  and  parity.  The  transmit 
logic  operates  at  2 MHz,  creating  a TTL  Manchester  output  format.  The  DCU 
supplies  a sync  select  line,  high  for  command  words  and  low  for  data  words, 
and  the  MTU  supplies  the  proper  sync  pattern  and  odd  parity  to  each  word. 

While  outputting  parity,  the  MTU  logic  examines  the  output  sequence  enable 
discrete  from  the  DCU  to  determine  whether  to  continue  another  output  or  to 
go  idle  disabling  both  drivers. 

The  DCU  supplies  two  "busy"  discrete  signals  to  the  MTU.  Either  signal 
in  a high  state  signifies  that  the  DCU  is  actively  involved  in  the  transaction  on 
the  bus  as  either  a bus  controller  or  a remote  terminal.  For  the  duration  of 
either  busy  signal,  the  MTU  logic  checks  for  valid  bit  or  parity  errors  posted 
at  the  end  of  each  received  word.  Any  detected  error  will  be  latched  and  trans- 
ferred to  a program  readable  register  when  1)  the  DCU  removes  the  busy  signal, 
or  2)  the  total  allowable  message  time  has  been  exceeded.  In  either  event,  a 
message  error  interrupt  is  issued  and  contents  of  the  error  register  will  remain 
latched  until  replaced  by  subsequent  message  errors.  The  current  message 
length  timer  is  set  for  768  fis.  Reaching  this  time  out  period  implies  a mal- 
function on  the  bus  and  a reset  is  issued  to  the  DCU  logic. 

Because  the  MTU  senses  all  bus  traffic,  error  checks  are  conducted  on 
DCU  output  as  well  as  input  words.  When  the  MTU  is  not  enabled  with  a DCU 
busy  signal,  errors  occurring  on  the  bus  are  ignored.  The  MTU  also  supplies 
a message  error  discrete  signal  during  DCU  busy  for  use  in  the  remote  terminal 
status  word.  The  error  status  byte  available  to  the  program  specifies  error  type 
(bit,  parity,  message  timeout)  plus  shut-off  discretes  from  the  line  drivers 
should  they  overheat  and  drop  out  and  which  bus  was  active  at  the  time, 

DUAL  DRIVER /RECEIVER 

The  Driver /Receiver  hybrid  provides  the  interface  between  the  Multiplex 
Terminal  Unit  and  one  of  two  MIL-STD-1  553A  data  busses.  Bus  switching  is 
under  program  control.  As  shown  in  Figure  7,  it  consists  of  two  sets  with  a 
driver  section,  a receiver  section,  isolation  resistors  and  coupling  transformers 
(external  to  the  hybrid). 
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Figure  5.  MTU  Sync  Detection,  Bit  Synchronization,  Bit  Validation  Tinning 


Figure  6.  MTU  Input  Word  Timing 


Figure  7.  Bus  Coupler  Block  Diagram 


i 
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The  driver  section  shown  in  Figure  8 is  designed  to  accept  a serial  TTL 
data  stream  and  produce  a bi-phase  signal  of  _+3V  minimum  to  ^lOV  maximum 
between  the  two  conductors  of  a 70i?  twisted  shielded  pair  cable.  Provision  is 
made  to  inhibit  the  transmitter  under  logic  control  or  it  ceases  driving  auto- 
matically when  excessive  current  is  drawn. 

The  receiver  section  shown  in  Figure  9 accepts  a Manchester-coded  bi-phase 
signal  of  jfZV  minimum  to  ^lOV  maximum  from  the  data  bus  and  produces  a pair 
of  TTL  compatible  signals  (TRUE,  TRUE).  The  receiver  has  provisions  for 
turning  power  off  when  not  in  use.  The  receiver  design  features  an  active  four 
pole  gaussian  low  pass  filter  and  positive/negative  threshold  detection  with 
hysteresis  for  improved  noise  rejection  and  reliability.  The  TRUE  output 
switches  to  logic  1 when  the  transformer  output  exceeds  600  mv.  The  TRUE 
output  switches  to  a logic  1 at  -600  mv.  The  outpus  return  to  logic  0 at  +6  mv, 
respectively.  Table  2 summarizes  driver /receiver  characteristics. 

Table  2.  Bus  Interface  Specifications 


Transmitting  (measured  after  isolation  resistors) 


V oltage  levels: 


+ 3V  min  +10V  max 


Load: 


Rise  time/Fall  time: 


up  to  300  ft.  of  cable  (Z^  = lOQ  _+10%  line  terminated 
at  each  end  with  and  up  to  33  other  terminals 

> 100  ns  (10%  to  90%) 


Zero  crossing 

deviation:  +25  nsec  from  ideal 


Protection: 


shorts  to  ground  and  current  exceeding  360  ma  for 
30  /vsec 


Standby 

Voltage  levels: 


return  to  0 +50  mv  within  2 fisec  after  last  bit 


I 
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Receiving 

Voltage  levels: 

Input  impedance: 

Noise  conditions: 

Noise  emitted 
from  receiver: 


^2V  min  ^1  OV  max  (clips  at  2V,  selectable) 

> 2200 

S/N  14  DB,  white,  gaussian  from  1 kHz  to  MHz 
10  mv  peak-to-peak 
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SUMMARY 


I' sing  a PROM  coded  pattern  correlation  technique  for  receiving  data  has 
proved  very  reliable  in  accurately  recognizing  syncs  and  data  bits  on  the  bus. 

The  stored  patterns  can  be  altered  and  expanded  as  necessary  for  noise  inimunity 
to  meet  the  required  word  error  rates.  Resyncing  at  8 MHz  on  each  incoming 
data  bit  also  enhances  reliability. 

Being  able  to  receive  while  transmitting  allows  the  interface  as  a Bus 
Controller  to  address  itself  as  a Remote  Terminal  providing  a 100%  closed- 
loop  self  test  capability.  It  also  permits  a certain  degree  of  MUX  Bus  system 
simulation  with  only  1 hardware  interface. 

It  was  felt  froni  the  beginning  that  some  time  limit  would  be  necessary  on 
every  message  — in  particular  where  short  word  count  errors  occur  or  a terniinal 
fails  to  respond  leaving  a bus  tied  up  with  no  traffic  on  it.  Thus  the  768  fjs  hard- 
ware timer  was  implemented  wliich  allows  recovery  from  incomplete  transactions. 
A dead-line  monitor  was  required  in  this  particular  application  to  assist  in  switch- 
ing control  from  the  prime  bus  controller  to  a secondary  backup  controller.  Tliis 
dead-line  discrete  indicates  no  traffic  for  at  least  65.  5 ms. 

It  was  considered  best  to  have  coniputer  software  manage  the  interface  on 
a per-message  basis  when  acting  as  Bus  Controller.  The  program  thus  knows 
when  and  where  errors  occur  and  may  alter  its  course  of  action  as  necessary. 
Minimum  demands  are  made  on  softwa  re  time.  The  program  can  output  controls 
for  the  next  message  while  the  current  niessage  is  in  progress.  A message  in 
progress  will  not  stop  under  program  control.  It  will  go  to  completion  and 
immediately  execute  what  has  been  loaded  in  queue  (if  anything).  Software  can, 
however,  stop  traffic  on  either  bus  at  any  time  by  manipulating  t)ie  bus  inhibit 
discretes. 
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TOWARDS  A UNIVERSAL  SYNCHRONOUS  COMMUNICATIONS  CHANNEL 
UTILIZING  MICROPROGRAMMED  DEVICES 

L.  L.  King 

Westinghouse  Defense  and  Electronic  Systems  Center 
Baltimore,  Maryland  21203 


Abstract 

This  paper  evaluates  the  feasibility  of  utilizing 
microprogrammed  devices  in  establishing  a universal  digital 
communications  channel.  A modular  approach  is  utilized  to 
achieve  higher  performance  in  line  speed (s)  and/or  the 
handling  of  complex  protocols  by  increasing  the  number 
of  microprocessors  along  with  other  LSI  devices  utilized. 
Communications  functions  are  distributed  to  the  micro- 
processors associated  with  a specific  configuration  without 
significant  destruction  of  the  utility  of  the  microcode 
postulated  for  a lower  performance  configuration. 


1.0  Introduction 


Universal  is  defined  by  Webster  as  "including  or  covering 
all  or  a whole  collectively  or  distributively  without  limit- 
ation or  exception."  As  applied  to  a communications  channel 
or  any  other  item,  set,  or  function,  this  idea  of  universality 
is  not  in  actuality  or  practicality  achievable.  However,  with 
the  advent  of  communications  standards,  medium  (MSI)  and 
large-scale  integration  (LSI)  and  especially  microprogrammed 
devices,  many  barriers  and  constraints  which  existed  have  been 
diminished  or  removed. 


2.0  Scope 


This  paper  will  investigate  the  feasibility  of  developing 
a "universal"  commtinications  channel  utilizing  micro- 
programmed devices.  The  approach  considered  is  to  begin  with 
a small  set  of  microprogrammable  devices  which  provides  a 
basic  communications  channel  capability  and  utilizing  modular 
techniques  for  both  firmware  and  hardware,  increase  the 
communications  channel  capability  to  a high  throughput  device. 
This  consideration  is  limited  to  the  necessary  fvinctional 
processes,  the  functional  process  allocation  to  different 
microprocessors  as  more  complex  channel  configurations  are 
considered,  and  the  probable  capability  achieved  by  each 
channel  configuration  considered.  Finally,  since  asynchronous 
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techniques  are  so  unique  and  are  limited  in  line  speed  operation, 
this  paper  will  consider,  only,  synchronous  type  information 
transmission . 

3.0  Functional  Requirements 

Several  functional  processes  are  required  to  achieve 
effective  operation  of  a digital  communications  channel  when 
LSI/MSI  microprogrammable  devices  are  utilized  or  are  required 
to  operate  a serial  digital  communications  device  itself. 

These  include  but  are  not  limited  to  the  following: 

a.  Serial  Line  Interface  Characteristics 

b.  Microprogrammed  device  characteristics 

c.  Line  and/or  Channel  Protocols 

d.  Computer/Channel  Interface  Characteristics 

e.  Support  Logic  Requirements 

3.1  Serial  Line  Interface  Characteristics 

Serial  Line  Interface  Characteristics  defines  the  electrical 
parameters  of  the  transmission  medium,  line  drivers  and 
receivers,  and,  if  necessary,  modem  controls  utilized  for 
transmiss.ion  of  an  electrical  signal  between  two  points. 

3.1.1  Transmission  Medium 

This  applies,  only,  if  the  transmission  medium  is 
utilized  to  directly  couple  or  "hard-wire"  two  or  more  com- 
munications channels  together.  The  most  popular  mediums 
utilized  are  twisted  pair  or  coax  or  triax  cabling. 

3.1.2  Line  Drivers  and  Receivers 

The  line  drivers  and  receivers  are  defined  in  several 
"commercial"  standards  provided  by  the  Electronic  Industries 
Association.  This  includes  EIA  RS-232,  RS-422,  RS-432,  and 
RS-439.  Military  requirements  similar  to  the  EIA  specifications 
are  described  in  the  appropriate  military  specifications 
and  standards. 

3.1.3  Modem  Control 

Modem  interfacing  and  control  is  described  in  the 
appropriate  commercial  and  military  specification. 

3.2  Microprogrammed  Devices  Characteristics 

The  performance  levels  of  these  LSI  and  MSI  devices  are 
controlled  by  the  device  technology  utilized  (TTL,  ECL, 
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MECL,  etc.)»  the  architecture  of  each  device,  and  capabilities 
provided  by  the  devices  for  construction  of  larger  systems  when 
multiple  devices  are  utilized. 

Two  categories  of  these  devices  are  available  for 
utilization.  These  include  the  "controller-on-a-chip"  and  the 
"bit  slice"  elements.  The  controller-on-a-chip  device 
provides  ail  of  the  logical  operations  necessary  for  functioning 
on  one  chip.  The  bit  slice  technology  provides  a certain 
number  of  parallel  bite  devices  and  requires  supporting 
devices  to  satisfy  the  necessary  logical  operations  require- 
ments. The  "bit/slice"  technology  provides  higher  logic 
rates  than  "device-on-chip"  technology.  However,  some  of 
the  new  single  chip  controllers  are  approaching  the  bit/slice 
technology  capability. 

3.3  Line  and/or  Channel  Protocols 

Protocols  are  defined  as  sets  of  procedures  required  to 
cause  transmission  and/or  receipt  of  data  across  the 
communication  line.  The  protocols  define  the  synchronization, 
data  and  timing  scheme (s)  utilized  for  alignment  and  movement 
of  data  across  the  transmission  medium. 

Two  different  categories  of  protocol  are  the  most  widely 
used.  These  include  character  or  bit  oriented  protocols  and 
are  described  in  the  appropriate  commercial  or  military 
specification . 

3.4  Computer/Channel  Interface  Characteristics 

The  basic  task  of  any  communications  channel  is  the 
transfer  of  data  between  two  or  more  computers  and/or  user 
devices.  To  accomplish  this  task  the  communication  channel 
must  be  tied  to  or  interfaced  with  the  higher  order  devices. 

The  modern  data  channel  must  assume  a major  role  in  the 
operations  of  interface.  These  functions  include  the  logic 
for  data  transfer  usually  as  a direct  memory  (DMA)  or  pro- 
grammed I/O  operation  responding  to  functional  control  from 
the  higher  order  device  and  performing  the  hand-shaking 
required. 

3.5  Support  Logic  Requirements 

These  are  defined  as  those  functions  required  to  support 
logical  operation  of  the  channel.  In  other  words,  this 
logic  does  not  contribute  to  the  logical  function  for  handling 
or  processing  the  information  for  message  flow  or  control  but 
actually  perform  support  task(s)  for  logic  performing  the 
message  flow. 


4.0  Channel  Operation  Evaluation 


The  primary  objective  of  this  paper  is  to  evaluate  the 
probability  of  developing  a universal  synchronous  digital 
communication  channel  using  microprogrammed  devices.  A 
series  of  functional  block  diagrams  is  utilized  to  demonstrate 
the  modularity  of  these  devices  and  to  show  the  allocations  of 
functions  between  the  microprocessor (s)  shown  in  the  different 
block  diagrams. 

Capability  estimates  for  the  different  configurations  are 
based  on  experience  gained  by  Westinghouse  in  the  integration  of 
complex  computer  systems  and  detailed  studies  performed  for 
several  different  customers.  These  capability  estimates  are 
considered  to  be  conservative. 

4.1  Basic  Performance  Level 

Figure  1 shows  the  basic  or  simplest  level  micro-device 
system  capable  of  performing  a communications  channel  function. 
Note  that  only  one  microdevice  is  utilized  to  perform  all  the 
functic.ial  task  necessary  for  communication  channel  operation. 
One  microprogram  provides  complete  channel  support  of  the 
functions  listed  on  the  diagram. 

4.2  Improved  Performance  Level 

Figure  2 shows  an  improved  performance  level  system 
capable  of  performing  a complex  communications  channel  function. 
This  improved  performance  includes  the  capability  of  handling 
a higher  level  protocol,  DMA  computer/channel  operation  and 
higher  line  speeds.  This  is  achieved  by  adding  a second  micro- 
processor to  the  basic  system  shown  in  Figure  1 and  distributing 
the  functions  between  the  two  microprocessors . The  dis- 
tribution of  these  functions  are  listed  in  Figure  2. 

Note  that  one  additional  functional  parameter  had  to  be 
added  to  both  processors.  This  is  the  communciations  required 
for  each  micro-device  to  synchronize  with  each  other. 

4.3  Higher  Performance  Level 

Figure  3 shows  a system  capable  of  performing  the  higher 
level  protocols  and  increased  throughput  speed  when  compared 
to  the  system  shown  in  Figure  2.  This  is  achieved  by  adding 
a RAM  buffer  and  a LSI  protocol  processor  to  the  Figure  2 
configuration . 

The  LSI  protocol  processor  can  either  be  a LSI  device 
that  is  specifically  designed  for  the  selected  protocol  or  a 
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microprocessor  specifically  programmed  to  handle  the  selected 
protocol.  In  either  case,  the  specially  designed  device  is 
much  more  efficient  than  the  programmed  microprocessor. 

The  RAM  memory  is  utilized  as  a buffer  to  the  computer  I/O 
system  and  eliminates  the  requirement  that  all  data  be  transferred 
through  the  microprocessors.  This  reduces  the  traffic  load 
on  the  microprocessors  and  permits  more  processor  time  for 
performing  other  functions.  Address  control  for  the  RAM 
memory  is  performed  by  using  two  address  pointers.  Micro- 
processor B controls  the  "Write"  pointer  and  Microprocessor  A 
controls  the  "Read"  pointer.  One  extra  bit  is  added  to  all 
memory  addresses  to  show  the  read/write  status  of  each  word. 

When  the  memory  location  is  written  into  the  bit,  it  is  set  to 
a logical  "one".  When  the  memory  location  is  read,  the  bit 
is  set  to  a logical  "zero".  By  checking  this  read/write 
status  the  microprocessors  assure  non-overlapping  performance. 

4.4  Maximum  Performance  Level 

Figure  4 shows  a configuration  capable  of  performing 
the  commune iat ions  channel  function  at  a near  maximum  rate. 

Note  that  these  are  duplicate  configurations  of  those  shown 
in  Figure  3 except  each  configuration  is  programmed  to 
perform  as  a simplex  channel.  Two  simplex  channels,  one  for 
input  and  one  for  output,  perform  the  full  duplex  channel 
tasks.  The  two  simplex  channels  are  interconnected  for 
coordination  of  functionally  assigned  tasks. 

5.0  Conclusions 

By  using  a modular  approach  in  the  development  of  a 
digital  communications  channel  a large  degree  of  universality 
can  be  achieved.  It  was  shown  that  a wide  band  of  line 
speeds  can  be  achieved  (1.2K  - IM  b/s) . The  channel  can  also 
be  expanded  to  handle  higher  level  protocols.  It  was  further 
demonstrated  that  channel  operation  functions  can  be  dis- 
tributed between  microprocessors. 
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IMPROVED  PERFORMANCE  FUNCTIONAL  BLOCK  DIAGRAM 
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ABSTRACT 


The  Systems  Engineering  Avionics  Facility  (SEAFAC) 
contains  a MIL-STD-1553  Data  Bus  Test  Bench.  The  Data  Bus 
has  various  remote  terminals  connected  to  it  and  it  was 
determined  that  some  type  of  test  equipment  was  needed  in 
order  to  initially  checkout  hardware  connected  to  the  data 
bus.  Since  that  time  several  pieces  of  equipment  have  been 
built.  Each  of  them  is  called  a Bus  Tester  and  is  numbered 
consecutively  in  the  order  of  design  (i.e.,  Bus  Tester  I, 
Bus  Tester  II,  etc.).  This  paper  will  describe  the  reasons 
for  and  general  operations  of  each  of  three  generations  of 
Bus  Testers. 

INTRODUCTION 

There  are  several  reasons  for  a Bus  Tester  - one  of 
which  is  to  keep  the  hardware  and  software  as  far  apart  as 
possible.  Without  some  type  of  Bus  Tester,  when  a hardware 
device  has  been  built,  the  hardware  person  has  to  rely  on 
software  personnel  for  checkout.  This  can  lead  to  head- 
aches determining  whose  wrong,  software  or  hardware.  By 
using  the  Bus  Tester  as  a BUS  CONTROLLER,  initial  hardware 
checkout  can  be  accomplished  without  the  need  for  any  soft- 
ware . 

A Bus  Tester  ds  also  needed  for  monitoring  the  Bus. 
Before  when  a person  looked  at  the  Bus  with  a scope,  with 
the  BUS  CONTROLLER  talking  asynchronously  to  more  than  one 
device,  it  is  difficult  to  sync  on  a particular  message, 
and  even  more  difficult  to  read  the  manchester  biphase  on 
the  scope.  Using  a Bus  Tester  which  can  selectively  pick 
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off  messages  and  display  them  allows  a person  to  look  at 
Bus  Traffic  for  one  RT.  Another  reason  for  a Bus  Tester  is 
for  error  detection  and  error  flagging. 

OPERATION  OF  THE  BUS  TESTERS 

The  first  generation  Bus  Testers  are  fundamentally 
limited  in  their  capabilities  and  are  used  mainly  in  ini- 
tial hardware  checkout  and  periodic  maintenance  checks. 

They  perform  two  functions;  that  of  a bus  monitor  and  an 
elementary  bus  controller.  A switch  on  the  front  panel  de- 
termines the  mode  of  operation. 

When  the  Bus  Tester  acts  as  a bus  monitor,  it  displays 
all  traffic  presently  on  the  data  bus.  Displayed  on  the 
front  panel  are  the  most  recent  command  word,  the  most 
recent  status  word  and  the  two  most  recent  data  words 
transmitted  on  the  data  bus. 

When  the  Bus  Tester  acts  as  a bus  controller,  it  sends 
commands  to  a remote  terminal  and  communicates  with  this 
remote  terminal.  The  Bus  Tester  outputs  a sixteen  bit  com- 
mand word,  entered  through  the  front  panel  switches.  The 
sixth  most  significant  bit  is  the  transmit/receive  (T/R) 
bit.  If  T/R  is  high,  the  remote  terminal  is  told  to  trans- 
mit a status  word  and  the  specified  number  of  data  words  to 
the  Bus  Tester,  v;hich  displays  them  on  the  front  panel.  If 
T/R  is  low,  the  remote  terminal  is  told  to  receive  data 
words  from  the  Bus  Tester  that  are  entered  through  the  six- 
teen data  word  switches  on  the  front  panel.  The  remote 
terminal  responds  with  a status  word,  that  is  displayed  by 
the  Bus  Tester. 

Bus  Tester  II  was  the  follow-on,  or  second  generation 
Bus  Tester  designed  and  built  within  SEAFAC.  Only  one 
module  unit  has  been  constructed.  This  tester  provides  all 
Bus  Tester  I capabilities  plus  an  expanded  capability  to 
provide  pre-programmed  monitoring  of  the  1553A  data  bus  and 
pre-programmed  message  transfer  on  the  bus.  It  also  pro- 
vides a means  to  display  various  error  rates.  This  gives  a 
sophisticated  means  of  monitoring  remote  terminals  for  ini- 
tial checkout,  maintenance  and  bus  observation.  It  has 
more  extensive  bus  controller  capabilities  than  Bus  Tester 
I.  This  tester  has  been  used  for  validation  of  some  con- 
tractor-developed equipment  and  has  been  requested  for 
future  validation  checks  by  others.  The  design  documen- 
tation has  been  requested  by  two  companies  and  the  legal 


654 


implications  of  providing  such  have  been  cleared  through 
the  base  Judge  Advocate  General  office.  The  design  has 
been  furnished  to  Northrop  Corporation,  Electro-Mechanical 
Division  for  use  in  their  test  facility,  and  it  will 
shortly  be  sent  to  the  Hoffman  Electronics  Company. 

Operation  of  the  Bus  Tester  is  via  front  panel 
switches.  A PROG/XEQ  switch  specifies  whether  the  tester 
is  in  the  programmed  phase  or  the  execution  phase.  In  the 
program  phase,  command  words  and  data  words  are  entered 
using  the  front  panel  switches.  For  example,  to  enter  a 
command  word  the  16  switches  under  the  displays  are  set  and 
the  ENTER  COMMAND  switch  is  pressed.  Data  words  are  en- 
tered in  the  same  manner  using  the  ENTER  DATA  switch  in 
conjunction  with  the  Data  Address  control  switches.  After 
programming  the  tester  the  PROG/XEQ  switch  is  placed  in  the 
XEQ  position  and  the  initiate  push  button  is  pressed.  The 
tester  has  two  modes  of  operation  which  are  controlled 
using  the  front  panel  switch  XMIT/LISTEN.  In  the  TRANSMIT 
mode  the  tester  acts  as  a bus  controller  and  transmits  a 
pre-programmed  conmiand  word  and  data  words  if  it  is  a 
receive  command  at  a rate  specified  by  the  XMIT  Delay 
switches.  In  the  LISTEN  mode  the  tester  monitors  the  bus 
and  displays  messages  corresponding  to  a i're-prov;(ranm\ed 
remote  terminal  address.  The  tester  can  also  detect  cer- 
tain errors  such  as  a status  no  response  from  a particular 
RT,  low  or  high  word  counts  and  if  tlie  T "F  or  M "E  bit  is 
set  in  a particular  RT  stvitus  word.  Control  of  error  de- 
tection is  done  using  front  panel  switches. 

A third  generation  Dus  Tester  was  needed  to  further 
test  the  operation  of  remote  terminals  connected  to  a data 
bus.  Terminals  which  operate  properly  when  sent  good  in- 
formation may  not  necessarily  operate  in  a desired  manner 
when  sent  bad  information.  Bus  Tester  III  will  have  all 
the  functions  of  Bus  Tester  II  plus  the  capability  to  do 
full  RT  veiif ication  and  validation  checks.  This  tester 
will  provide  fault  detection  tests  for  MTUs  by  generat ina 
errors  such  as  bad  sync  for  command  word  or  data  woid,  bai.i 
biphase,  or  bad  parity.  Bus  Tester  III  will  be  rack 
mounted  within  a permanent  test  console  alonvi  with  a PRi'>M 
programmer,  Hazeltine  2000,  Tektronix  bll  CRT,  two  t oi  ot' 
stick  hand  controllers,  and  power  supplies. 

Operation  of  Bus  Tester  III  is  as  specified  in  t lie 
paragraph  above  which  describes  the  operation  of  Bus  Testoi 
II.  A few  minor  changes  have  been  incorporated  in  the 
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design  and  are  readily  discovered  when  the  front  panel  lay- 
outs of  the  two  testers  are  compared.  When  operating  in 
the  transmit  mode  (or  as  a controller)  the  tester  can  be 
programmed  via  the  front  panel  switches  to  transmit  the 
following  types  of  errors:  parity,  short  or  long  words, 
too  few  or  too  many  data  words,  encoding  errors,  variable 
data  rate,  and  glitches  on  the  transmission  line.  The 
following  is  a brief  description  of  each: 

• parity  - any  single  word  may  have  a parity  error  or 
all  words  can  have  their  parity  bit  either  held 
high  (to  a logic  one) , held  low  (to  a logic  zero) 
or  inverted. 

• short  or  long  words  - all  words  transmitted  by  the 
tester  can  be  expanded  or  reduced  by  a maximum  of 
three  data  bits. 

• too  few  or  too  many  data  words  - any  number  of  data 
words  different  than  the  number  specified  in  the 
transmitted  command  word. 

• encoding  errors  - changing  the  biphase  code  and 
sync  of  any  word  transmitted. 

• variable  data  rate  - changing  the  bit  transmission 
rate  by  1 MHz  + Af. 

• glitch  on  line  - inflecting  narrow  pulses  anytime 
during  or  between  transmissions. 

In  addition  to  the  error  infliction  capability.  Bus 
Tester  III  can  operate  as  a controller  for  remote  terminal- 
to-remote  terminal  transfers.  The  tester  also  has  outputs 
for  single-line  hookup  to  a terminal  without  the  use  of  a 
main  bus  line  and  coupler  boxes. 
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SCI  Systems,  Inc. 
Huntsville,  Alabama 


ABSTRACT 

This  paper  describes  a small,  highly  flexible  interface  unit  designed 
for  the  exchange  of  selected  information  from  a MIL-STD-1553  data  bus  to 
an  advanced  flight  test  instrumentation  system.  The  unit  can  be  used  to 
monitor  the  on-board  data  bus  for  proper  operation  and  utilize  the  bus  data 
for  aircraft  performance  verification. 

The  flight  test  instrumentation  system  employs  an  internal  MIL-STD- 
1553  type  high  speed  serial  digital  data  bus  for  remote  data  acquisition. 
Therefore,  the  unit  serves  as  a monitor  at  the  aircraft  bus  and  a remote 
terminal  for  the  instrumentation  bus,  providing  a buffered  interface  for  the 
asynchronous  data  busses. 

The  bus  monitor  is  designed  for  compatibility  with  all  known  MIL-STD- 
1553,  Revision  A and  B bus  interfaces  and  protocols.  The  unit  control  logic 
is  mic reprogrammable  for  flexibility  in  case  future  modifications  of  bus 
protocol  or  timing  are  required.  The  decom  program  resides  in  an  alterable 
non-volatile  memory  providing  flexibility  for  aircraft  bus  sampling  program 
changes.  The  design  and  construction  allows  for  easy  adaptation  of  the 
instrumentation  interface  to  other  system  applications  requiring  interface  with 
MIL-STD-1553  data  busses. 

ADVANCED  AIRCRAFT  FLIGHT  TEST  SYSTEM 

The  advanced  aircraft  flight  test  instrumentation  system  is  designed 
as  flexible  general  purpose  equipment  for  the  Air  Force  Flight  Test  Center, 
Edwards  AFB,  California,  and  is  commonly  known  as  Airborne  Test 
Instrumentation  System  (ATIS).  ATIS  has  been  developed  to  provide  a 
standard  set  of  instrumentation  hardware  for  current  and  future  Air  Force 
flight  test  programs  and  is  in  use  on  AWACS,  Command  Post  and  F-l6 
A ire  raft. 

ATIS  is  a flexible  modular  data  acquisition  system  which  employs  stored 
program  remote  multiplexing  over  an  internal  serial  digital  data  bus  (party 
line).  .Figure  1 shows  an  ATIS  configuration  with  major  hardware  elements 
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and  the  monitor  which  interfaces  the  MIL-STD-1553  bus  with  the  ATIS 
internal  data  bus.  The  basic  ATIS  system  configuration  consists  of  System 
Control  Unit  communicating  with  analog  and  digital  remote  units  via  a high 
speed  serial  digital  data  bus  (party  line).  The  remote  units  are  used  to 
sample  a large  number  and  wide  variety  of  airframe  and  engine  measure- 
ments throughout  the  aircraft.  The  ATIS  hardware  is  pictured  in  Figure  2 
photograph.  The  following  is  a brief  description  of  the  basic  ATIS  system 
hardware  components  and  the  instrumentation  data  bus. 

System  Control  Unit  - Provides  control  of  up  to  32  remote  multiplexer  units, 
analog,  digital,  or  mix,  from  a preprogrammed  non-volatile  memory.  The 
SCU  accesses  the  selected  remote  units  and  channels  with  address /control 
words  and  formats  the  received  data  for  output  to  real  time  telemetry  or  on 
board  tape  recorder.  Storage  is  provided  for  up  to  16  software  controlled 
sampling  programs  and  data  formats  with  8 selectable  output  PCM  bit  rates 
from  4kbps  to  512kbps. 

Analog  Remote  Unit  - The  ARU  operates  under  control  of  the  SCU  via  the 
high  speed  party  line  and  provides  30  channels  of  analog  multiplexing.  The 
analog  input  signals  may  range  from +20MV  to  +10  volts  full  scale.  Pre- 
programmed gain  control  is  provided  for  each  channel  from  the  SCU  with  8 
selectable  gains  from  1 to  500,  The  analog  samples  are  converted  to  11  bits 
plus  sign  digital  words  in  a high  accuracy  self-calibrating  A/D  converter. 

The  12 -bits  are  transmitted  to  the  SCU  via  the  party  line  for  processing  and 
formatting. 

Signal  Conditioning  Assembly  - The  programmable  gain  and  offset  features 
of  the  ATIS  allow  the  ARU  to  handle  the  output  of  most  transducers  directly 
without  additional  signal  conditioning.  The  Signal  Conditioning  Assembly 
(SCA)  provides  flexible  modular  signal  conditioning,  filtering,  transducer 
excitation  and  remote  voltage  sensing  at  the  transducer  terminals  for 
situations  requiring  maximum  accuracy.  The  SCA  accommodates  up  to  ten 
(10)  signal  conditioning  modules  of  nine  (9)  types. 

Submultiplexer  Unit  - Analog  channel  capacity  of  the  ARU  can  be  expanded 
by  the  addition  of  the  submultiplexer.  Each  submux  allows  up  to  four  (4) 
channels  of  the  ARU  to  be  expanded  by  128  high  or  low  level  inputs,  32  for 
each  A RU  channel. 

Digital  Remote  Unit  - The  Digital  Remote  Unit  (DRU)  is  a modular  assembly 
for  the  conditioning  and  acquisition  of  digital  data.  The  DRU  consists  of  a 
Digital  Remote  Interface  Unit  (DRIU)  and  up  to  eight  (8)  modules  which  provide 
the  conditioning  for  six  (6)  signal  types,  including  serial  and  parallel  discretes, 
frequency,  elapsed  time  counter,  tape  header  generator,  and  pulse  totalizer. 
An  additional  module  for  decoding  high  power  output  discretes  is  provided 
for  driving  lamps,  relays  and  stepping  switches. 


General  Purpose  Airborne  Processor  - The  GPAP  subsystem  hardware  is 
available  for  optional  expansion  of  AT  IS  capabilities  to  include  real  time 
in-flight  data  processing;  display  and  printing.  The  subsystem  contains 
an  Airborne  Digital  Computer,  Digital  Line  Printer,  Pilots  Panel  Display 
and  control  switches  for  program  control  and  print  routine  selection. 
Selectable  software  programs  provide  data  reduction,  data  compression  and 
any  other  processing  routine  that  can  be  programmed  in  the  available 
memory. 

Optional  System  Controller  (Format  Control  Unit)  - The  Format  Control 
Unit  (FCU)  is  a low  cost  unit  which  provides  system  control  for  applications 
not  requiring  the  full  capability  of  the  ATIS  system.  The  FCU  utilizes  a 
solid  state  EPROM  for  program  storage,  has  a capacity  of  8 remote  units 
and  provides  a maximum  PCM  output  rate  of  128kbps. 

The  FCU  Programming  System  provides  an  easy  method  of  memory  program 
preparation,  checkout  using  a RAM  memory,  £ind  loading  and  verification  of 
the  EPROM  program. 

Ground  Support  Unit  - The  Ground  Support  Unit  (GSU)  provides  a capability 
for  operation  and  checkout  of  the  ATIS  in  laboratory  or  flight  line  environ- 
ment. The  major  components  of  the  support  system  are  a ruggedized 
minicomputer,  interactive  display  keyboard,  cartrifile  and  a control  and 
format  synchronization  subsystem.  Multiple  functions  are  performed  under 
control  of  "prompting"  software  which  provides  majcimum  operator 
capability  with  minimum  training  required.  A photograph  of  a typical 
mobile  support  unit  for  pre-flight  checkout  of  the  system  on  the  aircraft  is 
shown  in  Figure  3 photog  aph. 

Instrumentation  Data  Bus  - The  ATIS  data  bus  (party  line)  is  full  duplex 
utilizing  two  twisted  shielded  pair  cables  operating  at  l.Smbps.  One  cable  is 
the  address /command  line  from  the  System  Control  Unit  (SCU)  to  the  remote 
multiplexers  carrying  remote  unit  address,  chainnel  address  and  gain  setting 
for  the  analog  chemnels.  The  other  cable  carries  the  data  return  from  the 
remote  units  to  the  SCU.  The  modulation  technique  is  biphase  manchester, 
with  20  bit  words  «md  the  twisted  pair  is  transformer  coupled  at  the  terminals 
in  the  same  way  as  MIL-STD- 1 553,  The  word  and  message  structures  are 
different  from  1553  due  to  the  unique  requirements  of  the  instrumentation 
system.  The  bus  was  designed  prior  to  the  finalization  of  the  MIL-ST  D-1553 
original  version.  More  details  of  the  instrumentation  bus  will  be  covered 
in  the  data  bus  monitor  interface  description. 

Data  Bus  Interface  Unit  - Data  Bus  Interface  Unit  (DBIU)  is  the  designation 
chosen  for  the  ATIS  MIL-STD- 1553  monitor /decom  interface  unit.  The 


DBIU  functions  as  a remote  unit  on  the  instrumentation  data  bus,  MIl- 
STD-1553  transmissions  are  decoded  and  selected  words  pre-stored  In  the 
DBIU  data  buffer  memorv.  The  preprogrammed  memory  locations  are 
addressed  and  selected  data  is  acquired  by  the  ATIS  control  unit  via  the  hl({h 
speed  Instrumentation  data  bus.  A detailed  description  of  the  DBIU  design 
and  functional  capabilities  are  included  in  the  sections  to  follow. 

FUNCTIONAL  DESCRIPTION 

The  DBIU  provides  programmable  docommutation  capabilities  for  up  to 
fovir  (4)  MIL-STD-1553  aircraft  data  busses,  data  memory  storage  for  255 
data  bus  words  or  time-tag  correlation  words,  and  the  Interface  witl\  the 
ATIS  instrumentation  data  bus.  The  alterable  non-volatile  docom  memory  is 
functionally  organiaod  as  message  list  memory  for  alrcmft  data  bus  message 
identification,  and  word  list  memory  for  bus  word  and  time-tag  selection. 

The  data  memory  supplies  16  data  bits,  tJic  parity  bit,  bus  Identification  bits, 
and  data  update  rate  flags  for  aircraft  data  bus  words,  and  20  bits  of  time- 
tag  data  to  the  instrumentation  data  bus.  Control  functions  for  the  memories 
and  bos  interfaces  are  generated  by  a microprog rammable  control  sequencer. 
The  block  diagram  for  the  DBIU  is  shown  in  Figure  4. 

Avionics  Pus  Receiver  - The  bus  receiver  shown  in  Figure  5 interfaces 
four  (4)  aircraft  data  busses.  The  receiver  input  transformers  contain 
sufficient  windings  and  strap  options  to  provide  for  aircraft  data  bus  couplers 
utilizing  either  transformer  or  direct  bus  connections.  With  the  exception  of 
the  input  filters  and  threshold  detectors,  the  design  is  totally  digital,  con- 
sisting of  a rephasable  4 MHz  clock  synchronizer,  pulse  width  discriminator, 
valid  sync  detector,  error  detectors  for  invalid  Manchester  biphase  coding  and 
word  length,  and  registers  for  data,  parity,  bus  I.  D.  , aiid  data  status.  The 
data  status  Information  provides  sync  type  and  validity,  coding  and  word  length 
error  flags,  and  a data  ready  flag  to  the  control  sequencer  logic  for  micro- 
program control. 

The  bus  I.  D,  register  svipplios  five  1.  D.  lines  to  tlie  data  memory.  Four 
of  these  linos  indicate  reception  on  busses  1 tlirough  4 for  ATIS  system  con- 
figurations in  which  tlio  Control  Unit  is  used  in  tlie  12  bit  data  reply  mode. 

The  fifth  line  distinguishes  between  dat.a  reception  on  bus  1 and  2,  or  bus  3 
and  4,  for  the  ATIS  10  bit  data  reply  mode.  A strap  option  is  provided  to 
convert  this  lino  to  a bus  l/bus  2 flag  for  system  configurations  where  only 
two  aircraft  data  busses  are  monitored. 

Decom  Memorv  - The  docom  memory  is  implemented  with  tlnree  2048  word 
by  8 bits /word  EPROM's  contained  in  a bolt-on  modvUo  to  simplify  removal 
for  docom  format  programming.  The  n^emovy  is  organized  for  two  functions, 
message  identification  and  word  selection  wltliin  a message.  The  message 
identification  function  is  contained  in  two  EPROM's,  each  containing  a separate 


mesaage  list  program  selectable  by  either  an  external  switch  or  a connector 
strap.  The  first  eleven  data  bits  of  the  aircraft  data  bus  command  word, 
the  terminal  address  field,  T/R  bit,  and  the  subaddress /mode  field,  supply 
the  address  to  the  message  list  memory.  The  memory  data  output  provides 
a starting  address  to  the  address  counter  for  the  word  list  memory.  An  all 
I's  code  from  the  message  list  memory  indicates  that  no  data  is  required 
from  the  current  bus  message,  and  is  decoded  and  supplied  as  a flag  bit  to 
the  control  sequencer  for  microprogram  control. 


The  word  select  function  is  contained  in  the  third  EPROM,  which  is 
organized  as  four  512  word  programs  selectable  by  either  external  switches 
or  connector  straps.  Each  word  list  program  contains  word  select  data  for 
word  type  and  data  word  count,  and  data  memory  storage  addresses. 


Data  Memory  - the  data  memory  is  a multiple -port,  high  speed  bipolar 
memory  organized  as  256  words  by  24  bits/word.  The  data  memory  word 
format  is  shown  in  Figure  6.  Address  inputs  are  received  from  the  word 
list  memory,  time-tag  interface,  and  the  ATES  bus  interface.  Data  inputs 
are  received  from  the  aircraft  data  bus  receiver  register  and  the  time-tag 
interface.  Data  and  address  selection  is  made  by  the  control  sequencer. 
Memory  address  zero  is  dedicated  to  elapsed  time  counter  (ETC)  data  and 
is  updated  at  the  ETC  clock  rate. 


Aircraft  data  bus  words  are  formatted  as  16  data  bits,  the  parity  bit, 

2 data  update  rate  flags,  and  the  bus  I.  D.  flags.  The  update  rate  flags,  the 
staleness  (ST)  and  overflow  (OV)  bits,  indicate  the  memory  access  rate 
differences  between  selected  data  from  the  aircraft  bus  and  data  requests 
from  the  instrumentation  bus.  The  ST  flag  is  set  when  2 consecutive  instru- 
mentation bus  requests  are  made  for  non-updated  data  from  the  aircraft  bus. 
The  OV  flag  is  set  when  aircraft  bus  data  has  been  stored  twice  between 
instrumentation  bus  requests. 


Memory  data  for  the  instrumentation  bus  is  transmitted  in  two  reply 
words  as  shown  in  Figure  6.  To  ensure  data  correlation  for  the  two  reply 
words,  the  first  request  for  a given  address  loads  the  24  bit  memory  word 
into  the  instrumentation  bus  reply  register.  The  second  request  transmits 
the  second  half  of  the  word. 


Time -Tag  Interface  - The  DBIU  provides  two  methods  for  time  correlation, 
an  internal  elapsed  time  counter  (ETC),  and  interfaces  for  external  serial 
and  parallel  time  sources.  Decom  selection  of  internal  or  external  time- 
tags  for  data  memory  storage  is  derived  from  the  word-list  memory.  The 
external  serial/parallel  time-tag  source  is  selected  by  a remote  switch  or 
cotmector  strap.  The  ETC  is  a 20  bit  binary  counter  with  selectable  clock 
rates  of  1 KHz  or  10  KHz  by  a remote  switch  or  connector  strap.  The  counter 
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is  reset  by  a microcode  power-up  initialization  routine  or  an  eKternal  reset 
input.  Time-tag  staleness  between  data  word  and  time-tag  memory  storage 
is  1 count. 

ATIS  Bus  Interface  - The  ATB  instrumentation  bus  is  full  duplex,  transformer 
coupled,  1.5  MHz,  biphase  Manchester,  utilizing  a 1553  type  sync  pattern. 

The  address /command  bus  word  structure  for  the  DRIII  utilizes  20  bits:  3 
bit  time  positive  sync  followed  by  a biphase  "One”,  5 bit  Remote  Unit  I,  D.  , 

B bit  data  memory  address,  normal/sequential  flag  (ARU  only),  reply /no 
reply  flag,  and  a final  biphase  "One''.  The  unit  I.  D.  from  connector  straps, 
the  fixed  data  "Ones",  and  the  reply  flag  are  compared  to  tlie  address/ 
command  word  to  generate  data  memory  request.  The  reply  data  bus 
utilizes  IB  bit  words:  3 bit  time  positive  sync,  biphase  "One",  10  or  12  bit 
data,  digital/ analog  data  flag,  and  a final  biphase  "One".  In  tlie  10  bit  reply 
mode,  the  two  leading  bits  of  the  data  field  are  zeroes.  The  digital /analog 
nag  indicates  to  the  ATIS  Control  Unit  the  option  of  addition/ subtraction  of 
preprogrammed  offset  codes  for  analog  data. 

Control  Sequencer  - Aircraft  data  bus  message  and  word  synchronization, 
and  decom  and  data  memory  control  functions  are  provided  by  a high  speed, 
bipolar,  microprogrammable  sequencer.  The  sequencer  assembly  includes 
the  control  sequencer,  microprogram  memory,  pipeline  register,  and  a 
condition  code  (CC)  mux.  The  control  sequencer  features  3-level  subroutines, 
jump  and  branch  instructions,  and  a loop  timing  counter.  Instruction  execution 
rate  is  4 MHz.  The  microprogram  memory  is  implemented  with  fusible- 
link,  bipolar  PROMS  and  configured  as  512  words  by  32  bits/word,  while  the 
architecture  allows  for  up  to  409b  words.  Memory  outputs  are  clocked  into 
a pipeline  register  to  provide  stable  data  and  reduce  sequencer  loop  delays. 

The  microcode  data  field  includes  sequencer  instructions,  CC  mux  input 
select,  system  clock,  clear,  and  enable  signals,  and  loop  counter/jump  and 
branch  address  values.  The  CC  mux  selects  flag  inputs  for  conditional  jump 
and  branch  Instructions.  Inputs  include  aircraft  data  bus  receiver  status  and 
command  word  T/R  bit,  decom  flags  from  message  list  and  word  list  mem- 
ories, and  connector  strap  flags  for  bus  protocol  selection. 

FLEXIBLE  DECOMMUTATION/PROGRAMMINC. 

The  DBRI  provides  a number  of  decom  memory  programming  features  for 
aircraft  data  bus  message  and  word  selection,  and  simplified  programming 
techniques.  Memory  word  formats  are  shown  in  Figure  6.  Message  list 
data  is  contained  in  one  byte,  and  word  list  data  in  two  bytes.  The  word  list 
starting  address  accesses  programs  contained  in  512  word  pages;  so  only  the 
8 MSB's  of  the  address  need  be  programmed.  Two  message  list  programs  are 
externally  selectable.  Word  list  data  contains  two  word  formats,  word  type 
selection  and  data  memory  addresses.  The  word  type  byte  contains  an  end- 


of-mesaage  (EOM)  bit  to  indicate  that  no  further  data  ia  required  from  the 
current  bua  meaaage,  and  word  type  and  data  word  cou;«t  fields.  Four 
word  liat  programs  are  externally  selectable. 

The  word  type  field  selects  command,  status,  or  data  words  from  bus 
messages,  and  internal /external  time-tag  data  for  data  memory  storage. 

The  word  count  field  is  utilized  for  bus  data  word  selection,  and  internal/ 
external  time-tag  selection  by  utilizing  the  word  count  LSB  as  a flag  input 
to  the  control  sequencer  CC  mux.  Future  bus  protocol  changes  such  as 
additional  word  types,  word  counts  of  greater  than  32  words,  etc.  , arc  easily 
implemented  by  reformatting  the  word  list  memory  bytes/access. 

FUNCTIONAL  MODULARITY 

The  DBIU  electrical  and  mechanical  design,  and  functional  partitioning, 
provide  simple,  low  cost  adaptation  to  accommodate  present  and  future 
unique  protocols  on  both  the  aircraft  and  instrumentation  data  busses.  The 
aircraft  bus  receiver  interface  is  contained  on  two  PC  boards,  instrumentation 
bus  interface  on  two  boards,  the  time-tag  interface  on  one  board,  tlie  data 
memory  on  one  board,  and  the  control  sequencer  assembly  on  one  boarci. 
Possible  adaptations  include  word  length  and  bit  rates  on  the  serial  busses, 
a parallel  interface  for  the  instrumentation  bus,  data  memory  expansion, 
and  time-tag  frequencies,  word  lengths,  and  external  interfaces. 

Along  with  the  present  flexibility  provided  by  microprogrannning  and 
decom  programming,  the  functional  modularity  of  the  DBTl'  provides  bigblv 
flexible,  adaptable  bus  monitor  functions. 

PROG  RAMMING/TEST  EQUIPMENT 

Test  equipment  is  provided  for  flexible  bench  testing  and  decom  memory 
programming  without  requiring  an  operational  aircraft  bus  and  ATtS  system. 

A bus  simulator  provides  the  wide  variety  of  bus  messages,  word  types,  error 
conditions  and  signal  levels  required  to  simulate  the  MIL-STD- 1 '^‘^3  bus 
interface.  Also  included  as  part  of  the  test  equipment  is  an  ,ATTS/nBlU  l est 
Set.  This  imit  provides  a flexible  DBRl  control  over  a simulated  ATIS 
instrumentation  bus,  and  allows  the  functional  capabilities  of  the  DBIU  to  be 
tested  while  operating  with  a simulated  or  operational  ' bus. 

A microprocessor  controlled  Programmer  is  provided  for  flexible  pro- 
gramming of  the  DBIU  decom  memory  (EPRCMl.  An  internal  RAM  may  be 
programmed  manually  or  from  an  external  support  system  and  the  program 
checked  out  with  the  DBIU  prior  to  loading  into  the  EPROM.  The  memory 
module  is  plugged  into  the  Programmer  front  panel  for  erasure  with  a built- 
in  ultraviolet  (UV)  light  source.  The  program  in  RAM  can  then  be  loailed  into 
the  EPROM  under  control  of  the  front  panel  switches. 


PHYSICAL  AND  ENVIRONMENTAL  CHARACTERISTICS 


As  with  all  ATIS  hardware  the  DBIU  is  designed  for  and  qualified  to 
the  severe  environmental  conditions  experienced  in  uncontrolled  spaces 
on  modern  high  performance  aircraft.  The  following  is  a listing  of  the 
physical  characteristics  and  operational  environmental  conditions  which  are 
a part  of  the  DBIU  design  requirements. 

o Size  - 8.  00  X 5.00  x 3.50  inches  (basic  housing  similar  to 
ARU,  without  decom  memory  module).  8.00  x 5.  00  x 4.25 
inches  (with  8.00  x 5.00  x 0.75  inch  decom  memory  module), 
o Weight  - 7.0  pounds,  maximum 

o Power  Dissipation  - 20  watts,  max.  at  28VDC 
o Temperature  — 54°C  to  +85°C 

o Altitude  - 0-70,000  feet 

o Relative  Humidity  - 95%  @ 71°C 

o Vibration  - 5 to  20  Hz  @ 0.  10  inch  DA;  20  to  33  Hz  @ 2 g accel. ; 

33  to  74  Hz  @ 0.036  inch  DA;  74  to  200  Hz  @ 10  g accel. 
o Electromagnetic  Compatibility  - MIL-STD-46 lA , CE03,  CE04, 
RE04,  RS04 

o Shock  - Half  sine  shock  pulse  - MIL-STD-810B  Fig.  516.  1-2, 
Procedure  III,  Flight  Vehicle  Equipment 
A - Peak  Acceleration  - 30g 
B « Pulse  Duration  - 1 1 millisec. 
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LOGIC  STRUCTURE  FOR  TESTABILITY  AND  FAILURE  DETECTION 


U.  Schulz  and  A.  Roelker 


DORNIER  SYSTEM  GMBH,  GERMANY 


ABSTRACT 


A concept  of  the  logic  structure  for  testability  and  failure 
detection  of  digital,  modular,  onboard  data  acquisition  and 
control  units  within  avionics  systems  will  be  presented. 

The  units  of  the  avionics  system  are  interconnected  by  the 
Serial  Data  Bus  (1553). 

The  concept  was  developed  according  to  the  maintenance  levels 
within  the  German  Air  Force.  The  tests  and  failure  detection 
are  performed  during  operation  as  well  as  during  pre-  and 
post  flight  tests  without  additional  external  special  to  type 
test  equipments.  The  tests  are  totaly  integrated  into  the 
avionic  system. 

The  tests  result  in  the  localization  of  the  failure  on  the 
defective  module  within  a unit.  The  test-software  needs  about 
4 msec  and  may  therefore  incorporated  into  the  operational 
software. 

This  leads  during  operationCinf light) to  a reorganization  of 
the  system  by  software  such  that  the  full  system  capability 
will  be  kept  until  a second  failure  occurs. 

This  system  capacity  is  performed  by  a minimum  of  additional 
hardware  (5  %)  and  testsoftware  (10  %) . 
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1 . INTRODUCTION 

The  conventional  structure  of  onboard  electronic  and  avionic 
system  is  purely  a collection  of  units  and  subsystems  (for 
example;  navigation,  guidance  and  control,  communication, 
displays,  ...)  which  are  separated  and  independent  from  each 
other.  The  failure  detection  and  testing  of  such  systems  is 
performed  by  many  special  to  type  testequipments  for  pre- 
and  postflight  tests  as  well  as  for  maintenance  tests. 
Testing  during  operation  is  nearly  impossible  except  the 
monitoring  of  a failure  of  a complete  subsystem. 

A concept  for  the  testability  and  failure  detection  of 
integrated,  digital  onboard  electronics  within  avionic 
systems  is  presented.  The  system  makes  use  of  the  inherent 
redundancy . 


2 . ASSUMPTIONS 

The  following  assumptions  are  made: 

- The  avionic  system  is  structured  as  an  integrated  data 
processing  system  with  a uniform  structure  concerning  the 
signal  processing  soft-  and  hardware. 

- The  system  contains  partially  redundant  units  due  to  the 
specified  reliability  of  the  subsystems. 

- The  signal  processing  units  are  line  replaceable  units  (LRU) 
and  interconnected  by  the  serial  data  bus  according  to 
MIL-STD  1553. 

- The  internal  structure  of  the  LRU's  is  modular  with  the 
modules  connected  and  operated  via  a parallel  data  bus.  The 
modules  are  functional  electronic  boards  as  multiplexer , 
A/D-converters,  digital  inputs  and  outputs,  ... 

- Most  of  the  LRU's  are  controlled  by  an  internal  processor. 

The  following  approach  on  testability  and  failure  detection  is 

based  on  the  system  shown  in  figure  1.  This  is  an  example  of 

an  avionic  system  design  for  a helicopter  for  which  the 

previous  mentioned  assumptions  are  valid. 
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3.  CONSIDERATION  OF  THE  PROBLEM 

The  failure  detection  and  testing  is  divided  into  two  main 
levels,  according  to  the  so  called  maintenance  levels  of 
the  German  Air  Force,  figure  2: 

o Testlevel  1: 

During  the  testlevel  1 the  inflight  test  and  the  pre-  and 
postflight  test  will  be  performed.  The  task  of  the  tests  are 
to  detect  the  failed  function  of  the  system  during  operation. 

o Testlevel  2; 

The  testlevel  2 is  the  first  maintenance  level.  The  tasks 
of  the  tests  are  to  detect  the  failed  hardware  components. 

The  failure  detection  during  operation  (test  level  1)  is 
performed  by  well  known  methods.  Those  methods  are  the  ob- 
servation of  the  process,  the  comparison  of  redundant  sensor- 
signals,  the  voting  of  the  results  form  the  algorithms 
within  redundant  data  processing  units. 

Therefore  the  following  considervations  are  limited  to  the 
maintenance  tests. 


4.  HARDWARE  TE.STAHILITY 

The  maintenance  tost  has  to  lead  to  the  detection  of  the  failed 
hardware  components.  The  considered  system  (see  figure  l)  has 
a uniform  structure  of  the  signal  processing  soft-  and  hardware, 
with  LRU's  built  up  with  standard  modules. 

F'igure  3 shows  the  general  configuration  of  a modular  LRU 
with  an  electronicai ly  and  mechanically  standardized  parallel 
data  bus  for  the  internal  data  transfers  and  the  serial  bus 
coupling  module  for  tlie  external  connections  to  the  other  units. 
The  units  contain  furtliei  a data  processor,  a memory,  ItAM  or 
PROM,  some  autonomous  modules  that  are  only  loeded  for  the 
control  of  the  internal  events,  and  a lot  of  digital  and 
analog  T/O-modviles  that  perform  the  connect  ion  to  the  prmx'ss. 

If  we  want  to  test  such  a system  we  must  have  testable  hardware. 
Kig  4 shows  the  structure  (.•'f  a testable  analog  perlphcrie.  We 
get  tin*  testability  by  using  the  inherent  ii dundancy  of  the 
nu*dules.  Tlu’  n-  and  m-input  signals  are  given  into  the  both 
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input  modules  and  are  given  back  again  to  the  system  by 
additional  wiring  from  the  outputs  to  the  inputs  (cross 
strapping) . The  test  itself  than  is  performed  by  software 
such  that  a failure  within  the  analog  peripherie  may  be 
detected  and  localized  down  to  the  level  of  analog  input  or 
output  modules. 

The  figure  5 shows  the  structure  of  a testable  digital 
I/O-module.  Here  some  circuits  are  added  to  the  pure  modulo 
function  of  every  module  in  order  to  set  up  the  test 
information  and  to  send  it  on  a "digital  test  bus".  The 
test  information  is  converted  to  a serial  4-bit  signal. 

The  figure  6 shows  the  receiver  module  that  is  connected  to 
the  parallel  memory  bus  of  the  data  processor.  The  test 
information  than  is  transfered  directly  to  the  registers  cf  the 
data  processor  and  there  compared  against  the  measurement  value 
that  comes  directly  over  the  data  bus  from  the  module. 

The  additional  hardware  consists  only  in  one  receiver  module, 
the  circuits  on  the  electronic  boards  and  the  wiring  of  the 
serial  test  bus.  The  tests  itselves  are  made  by  software. 

Figure  7 shows  an  example  of  a realized  LRU  within  an 
experimental  flight  guidance  and  control  system.  The  LRU  is 
prepared  for  the  maintenance  test. 

The  analog  periphery  is  tested  as  described  before.  The 
additional  wiring  (cross  strapping)  was  realized  as  shown  in 
figure  4.  The  test  of  the  analog  periphery  includes  the 
filtering  modules  and  phase  selective  rectifiers. 

The  digital  input  and  the  parallel  data  bus  are  tested  by 
means  of  an  additional  module,  the  data  way  memory. 

A failure  of  a bus  line  for  example  is  detected  by  transmitting 
a testsignal  through  the  bus  to  the  register  of  the  data  way 
memory.  It  is  transmitted  back  to  the  processor 
at  one  way  through  the  bus  and  at  a second  way  via  the 
process-side  and  the  digital  input.  The  wiring  between  data 
way  module  and  digital  input  is  performed  such  that  the  first 
8 bits  of  the  test  signal  are  given  back  to  the  processor 
through  the  last  8 bit  bus  lines  and  vice  versa. 

The  test  of  the  LRU  consists  further  of  short  tests  of 
autonomous  modules  (clocks,  ...),  the  data  transfer  via  the 
serial  bus,  the  processor  itself,  the  memory  and  power  modules 
inside  the  LRU. 


I’U.IMl  tist  inis 


From  investigation  and  tests  we  got  the  following  results. 


Considering  the  results  of  all  tests  and  their  logical 
combination  the  test  leads  to  a localization  of  the 
defective  module. 

The  calculation  of  such  a test  takes  about  500  command  words 
and  a time  of  about  4 msec. 

This  leads  to  the  possibility  to  perform  the  test  at  every' 
calculation  cycle  of  the  processor  while  the  system  is  full 
operating . 

Due  to  this  capability  of  failure  localization  at  the  level  of 
the  module  during  the  operational  mode  it  is  possible  to 
reorganize  the  software  of  a LRU  after  the  detection  of  a 
failed  module.  The  information  for  example  coming  from  an 
analog  input  may  be  replaced  in  case  of  a failure  of  the 
module  by  a value  that  is  calculated  from  redundant 
informations  within  the  system  (additional  observer) . 

Figure  8 shows  the  block  diagram  of  the  software  structure 
of  a LRU.  The  test  software  now  is  incorporated  into  the 
operational  software.  The  chosen  test  procedure  depends  on  the 
system  configuration.  The  organisation  and  timing  of  the 
complete  software  is  performed  by  a task  sceduler. 

After  the  discussion  of  the  testability  of  one  LRU  the 
maintenance  test  of  the  whole  system  (see  figure  1)  is 
considered . 

In  priiiciple  there  are  two  possibiiites  to  realize  the 
maintenance  test: 

1.  The  test  will  be  performed  by  a simple  external  tost 
terminal  with  the  test  software  sitviated  in  tlte  memory 
of  every  LRU  and  the  task  sceduler  in  the  terminal. 

2.  The  test  will  be  performed  by  internal  test  procedures 
that  are  situated  completely  within  the  memories  of  the 
LRU's  and  performed  and  control led  by  one  LRU  beinq  the 
master  on  the  serial  data  bus. 

An  example  for  the  configuration  of  an  external  test 
terminal  is  shown  in  the  figure  9.  The  whole  system  is 
connected  to  the  control  and  test  terminal  (CTT)  via  the 
standard  interface  of  the  serial  data  bus.  With  this 
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configuration  the  whole  system  may  be  tested  with  the  CTT 
being  the  master  on  the  bus.  On  principle  the  same  confi- 
guration is  valid  if  the  test  will  be  perfoirmed  by  internal 
test  procedures.  In  this  case  the  communication  between 
the  system  under  test  and  the  operator  may  be  performed  via  a 
multifunction  display  and  a multifunction  keyboard  in  the 
cockpit  (see  figure  1). 


5.  FINAL  CONSIDERATIONS 


Inflight-,  pre-  and  postf light-test  as  well  as  the  maintenance 
test  according  to  the  testlevels  1 and  2 may  be  performed  and 
totaly  integrated  into  the  system. 

There  is  the  possibility  to  detect  the  failed  function  of 
the  system  and  to  localize  the  failure  at  the  level  of  the 
module  within  the  LRU. 


There  is  no  need  of  any  external  test  equipment  if  the  result 
of  the  failure  detection  and  the  test  may  be  indicated 
(immediately  or  on  request)  on  a multifunction  display  in 
the  cockpit.  The  decision  whether  the  information  of  the 
failure  must  be  indicated  immediately  or  on  request  depends 
upon  the  importance  of  the  failure  and  its  influence  at  the 
operational  mission  during  the  flight.  During  pre-,  post- 
viight  and  maintenance  test  all  results  might  be  indicated. 


With  respect  to  the  testable  hardware  and  the  methods  of 
failure  detection  within  redundant  systems  it  is  possible 
to  allow  one  detected  failure  without  degradation  during 
operation  (inflight) . The  software  of  the  failed  LRU  will 
be  reorganized  as  discribed  above.  The  full  system 
capability  will  be  kept  until  a second  failure  occurs. 

This  is  especially  interesting  for  example  in  the  c ase  of  a 
triplex  guidance  and  control  system. 


I 
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This  capacity  of  the  system  is  performed  by  a minimum  of 
hardware  (5  %)  and  the  test  software  (10  %)  incorporated 
into  the  operational  software  program  of  the  system. 
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DIGITAL  DATA  ACQUISITION  SYSTEM  (D-DAS)  - 
A FLEXIBLE  TOOL  FOR  SIMULATION,  DEBUG,  and  TRAFFIC 
MONITORING  OF  1553  SYSTEMS 


By:  Michael  Boice 
EMM/SESCO 

Severe  Environment  Systems  Company 
A subsidiary  of 

Electronic  Memories  & Magnetics  Corp. 


The  Severe  Environment  Systems  Company  (SESCO)  has  developed  a highly  sophisti- 
cated and  extremely  flexible  instrumentation  system  for  numerous  1553  applications.  As  a 
passive  monitoring  system,  D-DAS  is  capable  of  on-line  data  compression,  thereby  elimi- 
nating the  recording  of  insignificant  data  and  reducing  the  time  necessary  for  interpreta- 
tion of  test  results.  This  system  finds  ready  application  in  the  testing  and  debug  of  1553 
systems  and  is  also  usable  as  a mass  memory  peripheral. 


PRECSmtU  PAOS  hi.Any 


The  proliferation  of  the  MIL-STD-tSSS  Bus  has  greatly  simplified  the  integration  of  avi- 
onics systems,  and  has  provided  a sufficient  product  base  to  warrant  the  development  of 
specialized  systems  hitherto  impracticai  dur  to  prohibitive  engineering  costs.  This  is  well 
exemplified  by  EMM/SESCO’s  D-D^S  product,  a highiy  sophisticated  system  peripheral 
I capable  of  numerous  functional  activities  while  utilizing  a common  hardware  configuration. 

EMM/SESCO’s  O-OAS,  as  shown  in  Figure  No.  1 - Biock  Diagram,  consists  of  a micro- 
programmed 1553  interface,  the  internal  SECS-2 16  bit  minicomputer,  a ROM  4K  x 16 
control  store.  Interface  logic,  a tape  controiier  and  two  23  megabit  SETS-1  tape  systems. 
These  components,  including  power  supply,  are  housed  in  a 1 / 2 ATR  enclosure.  Figure 
No.  2,  with  individual  modules  conduction  cooled  by  integral  heat-sinks  to  the  side 
walls.  Power  can  be  28  vdc  or  110  vac  50-400Hz.  The  system  conforms  to  MIL-E-5400 
specifications. 

The  0-DAS  1553A  interface  contains  the  dual  bus  interface  circuitry,  the  serial  to  paral- 
lel converters,  a DMA  Interface  to  the  internal  EMM  BUS,  and  eight  2K  x 1 message 
seiection  tables.  The  electrical  components  include  proven  transformer  and  standard 
hybrid  transmit /receive  devices.  The  encoding  and  decoding  of  the  Manchester  signal  is 
accomplished  utilizing  the  HDK-15530-8,  manufactured  by  Harris  Semiconductor.  This 
device  aiso  accommodates  the  checking  of  word  count  validity  and  proviaes  a convenient 
means  of  serializing  and  deserializing  the  16  bit  command,  data,  and  status  words.  An 
AMD  2911  sequencer  is  the  central  element  of  the  1553  command  sequencer.  A 1 K x 16 
control  itOM  is  utiiized  to  implement  the  synchronization  algorithm,  the  required  1553 
protocol  and  the  response  to  mode  commands. 

The  SECS-2  minicomputer  card  set  is  a microprogrammed  minicomputer.  Included  is  the 
capability  to  perform  hardware  fixed  point  arithmetic  and  to  allow  direct  implementation  of 
multiply,  divide,  and  multiple  shifting.  Double  precision  32-bit  words  can  also  be  handled. 
The  four  basic  single  precision,  floating  point  arithmetic  operations  are  also  programmed. 
The  standard  system  offers  a modified  I/O  and  interrupt  structure  (EMMBUS)  suitable  for 
efficient  data  transfer.  A compatible  I/O  is  optionally  available  for  hook-up  to  existing  stan- 
dard peripherals.  The  basic  card  set  consists  of  four  6M?”  x4V4”  plug-in  cards.  The  four 
cards  include:  (1)  the  Microcontrol  Card,  (2)  the  Data  Card,  (3)  Logic  Card  A,  and  (4)  Logic 
Card  B. 

The  SETS-1  is  a high-performance  digital  data  storage  unit  developed  by  SEPD  for 
severe  environment  military,  aerospace,  and  industrial  applications.  The  basic  SETS-1 
consists  of  a compact  transport  module  and  a removable,  sealed  tape  module.  Housed  in 
the  transport  module  are  drive  and  I/O  circuits,  and  the  solid-state  D.C.  brushless  motor. 
The  environmentally-sealed  tape  module,  interchangeable  between  transports,  contains 
300  feet  of  wide  temperature  tape,  a four-track  Read /Write  head,  and  coaxial  reels  with 
capstan  drive,  tape  guides,  and  tape  position  sensing.  Data  can  be  recorded  at  a density  of 
1600  bpi  for  23  Mbits  of  storage. 

The  primary  utilization  of  the  D-DAS  hardware  configuration  is  as  a passive  bus  monitor 
for  flight  test  and  system  debug  applications.  In  this  role,  a complex  microprogrammed 
algorithm^  traces  each  1553  message  to  maintain  the  D-DAS  in  proper  synchronization,  i .e., 
not  confuse  a status  word  with  a command  word . 


1 . Synchronization  algorithm  and  recorded  data  format  developed  in  conjunction  with 
Captain  L.  S.  Dougherty  AFAL/AA/DAIS. 
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When  a command  word  Is  encountered  which  matches  one  which  the  user  programmed 
as  significant,  the  1553  Interface  transfers  the  message,  along  with  a sixteen  or  32-blt  time 
of  day  tag  Into  Its  4K  x 16  RAM  memory.  This  process  Is  repeated  until  a data  record 
approximately  2K  x 16  In  length  Is  established.  This  record  is  then  transfei  red  to  the 
SETS-1  magnetic  tape  recorders  contained  In  Q-DAS. 

The  D-DAS  1553  Interface  contains  a single  2716  type,  socketed  EPROM,  which  is  user 
programmed  to  establish  the  appropriate  message  selection  tables.  This  enables  the  pre- 
programming of  eight  2K  x 1 message  tables  which  are  then  selectable  via  front  panel 
control  or  by  the  system  bus  controller. 

When  recording  data  in  the  specified  format  of  Figure  No.  3,  the  D-DAS  shall  be  capable 
of  recording  1300  records  of  information  where  each  record  contains  2048  by  16  bit  words, 
with  a maximum  total  storage  of  46  million  bits.  The  system  is  capable  of  transferring  data 
to  or  from  the  SETS-1  at  a rate  of  48,000  or  192,000  bits  per  second  as  selected  by  front 
panel  switch  settings. 

To  provide  a Range  Time  reference,  D-DAS  is  capable  of  accommodating  an  external 
IRIG-B  format  time-of-year  code  generator.  D-DAS  decodes  this  serial  PCM  input  and  uti- 
lizes it  to  time  tag  the  messages  received  with  absolute  range  time.  As  an  additional 
feature,  the  D-DAS  also  acts  as  the  RT  for  the  time-of-year  generator  which  can  therefore 
be  accessed  via  the  1553  Bus  as  a D-DAS  subaddress. 

While  In  the  passive  operational  mode.  D-DAS  is  initialized  by  its  front  panel  controls  to 
its  RT  address,  functional  mode,  and  appropriate  user  message  table.  In  this  mode,  there  Is 
absolutely  no  reconfiguration  or  modification  necessary  to  the  host  system  and  the  D-DAS 
is  totally  transparent  to  the  systems  being  monitored  as  well  as  the  bus  controller.  The  user 
thus  need  make  no  hardware  or  software  modifications  to  the  system  under  test  other  than 
the  physical  connection  of  the  D-DAS  to  the  1553  bus. 

While  this  mode  of  operation  represents  a significant  advancement  in  system  instrumen- 
tation, the  user  can  achieve  substantially  more  efficient  D-DAS  utilization  by  incorporating 
minimal  changes  in  bus  controller  software.  When  ine  Control  Authority  switch  on  the 
D-DAS  front  panel  is  in  the  bus  position,  the  D-DAS  control  word  can  be  accessed  and 
modified  via  the  1553  bus.  This  enables  the  bus  controller  to  start  and  stop  the  monitor 
function,  switch  the  active  message  tables  and  even  prebiock  and  send  data  to  the  D-DAS 
Thus,  the  user  may  activate  the  D-DAS  only  during  significant  portions  of  a test,  .?nd  select 
the  appropriate  message  selection  table  for  each  test  phase. 

As  the  aforementioned  2K  x 16  records  are  accumulated,  they  are  formatted  into  records 
as  shown  in  Figure  No.  3.  The  initial  message  is  preceded  by  a 32-bit  time  of  year  tag  as 
obtained  from  the  external  time  code  generator  and  all  subsequent  messages  are  preceded 
by  a 16-bit  interval  time  in  relation  to  the  first  message.  This  format,  developed  m conjunc- 
tion with  W-PAFBI  allows  for  easy  interpretation  of  data  and  also  enables  one  to  integrate 
composite  records  in  applications  where  multiple  D-DAS  units  are  used. 


1 Synchronization  algorithm  and  recorded  data  format  developed  in  conjunction  with 
Captain  L.  S.  Dougherty  AFAL/AA/DAIS. 
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Ground  based  data  transfer  can  be  achieved  by  one  of  two  methods.  Either  the  entire 
D-DAS  unit  can  be  removed  from  the  test  vehicle  and  the  data  removed  via  the  1553  bus 
utilizing  the  protocol  defined  by  the  B52  OAS/  DTU,  or  oniy  the  SETS  tape  cartridges  re- 
niov^  and  a ground  based  SETS  recorder  used  to  playback  the  data  (Interfaces  are  avail- 
able for  the  SETS-1  to  several  commercial  minicomputers).  EMM/SESCO  also  envisions 
development  of  a “quick  look”  ground  station  utilizing  a minicomputer,  a nine  track  1 12 
inch  tape  unit,  a video,  and  a floppy  disk  which  will  not  only  be  capable  of  transferring  the 
data  to  a nine  track  format  for  analysis  but  will  also  be  user  configurable  such  that  test  data 
can  be  immediately  examined,  by  parameter,  in  engineering  units  easily  interpretable  by 
teat  personnel.  ’ ^ / 


While  the  advantages  of  [>-DAS  In  Instrumentations  and  debug  of  1553  systems  is 
^tently  obvious,  the  development  of  a “quick  look”  ground  station  can  extend  its  function 
beyond  the  flight  test  itself  to  where  D-DAS  can  be  utilized  for  both  training  and  piiot 
evaiuation.  The  evolution  of  “realistic”  training  missions  has  greatiy  complicated  theeval- 
uation  of  pilot  performance  to  the  point  that  extensive  monitoring  systems  are  necessary. 
Without  rapid  and  accurate  feedback,  training  missions  are  very  limited  in  being  able  to 
improve  individual  pilot  performance.  A partial  solution  to  this  problem  has  been  imple- 
ment^ in  video  recording  of  the  heads  up  display  in  modern  training.  This,  however  can- 
not achieve  a total  level  of  cognizance  with  regard  to  pilot  interaction  with,  and  function  of 
theav  onics  system.  Utilization  of  a D-DAS  tape  system  with  a “quick  look”  ground  station 
capable  of  integrating  both  1553  and  video  data  would  provide  a level  of  sophistication 
which  will  dramatically  improve  the  training  feedback  available  and  thus  accomplish  the 
training  function  in  a more  expeditious  and  cost  effective  manner. 


Another  application  of  the  D-DAS  hardware  set  which  is  a natural  outgrowth  of  the 
passive  bus  monitor  function  is  that  of  a 1553  mass  memory  peripheral.  The  protocol  esta- 
blished for  the  playback  of  prerecorded  tapes  via  the  multiplex  data  bus  also  provides  a set 
of  tape  function  commands  such  that  the  unit  can  be  accessed  as  a Mass  Tape  Memory  by 
either  the  bus  controller  or  other  RT . The  D-DAS  can  therefore  be  used  for  both  Initial  Pro- 
gram Load,  Program  and  Data  storage  for  any  or  all  systems  on  the  data  bus.  The  remov- 
able SETS-1  cartridges  provide  a convenient  method  by  which  programs  and  data  can  be 
transported  between  ground  loaders  and  the  on  board  avionics  system. 


The  flexible  D-DAS  hardware  set  is  capable  of  satisfying  numerous  functions  and  is 
applicable  to  any  system  utilizing  the  1553  multiplex  data  bus.  This  paper  has  described 
several  of  these  including  the  passive  data  bus  Instrumentation  system,  and  a mass  mem- 
ory ^ripheral.  As  the  internal  D-DAS  processor  may  be  user  programmable,  its  ultimate 
applications  are  limited  only  to  the  Imagination  of  the  system  Integrator  or  end  user. 
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DATA  BUS  SIMULATION  AND  TESTING  ON 


THE  SPACE  SHUTTLE  PROGRAM 


Michael  R.  Sottile 
Singer-Kearfott  Division 
Little  Falls,  N.J. 


ABSTRACT 

This  paper  discusses  the  analysis  and  performance  verifi- 
cation of  the  Space  Shuttle  Data  Bus  configurations.  The  analytic 
approach  for  the  development  of  a Word  Error  Rate  model  is  dis- 
cussed and  typical  results  are  presented. 

To  verify  the  analytic  results  and  to  substantiate  mux  system 
performance,  several  Space  Shuttle  Data  Buses  were  constructed 
using  MIA's  and  the  Space  Shuttle  Data  Bus  Cable  and  tests  per- 
formed; cimong  many  others,  these  included  WER  and  waveform  fi- 
delity. Also,  data  was  taken  to  determine  how  Word  Error  Rate 
varied  parcunetrically  with  signal  rise  time,  signal  offset,  in- 
ternal threshold  voltages,  rms  noise  levels,  signal  offset,  tem- 
perature and  signal  amplitude. 
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INTRODUCTION 


I 


The  Space  Shuttle  Multiplex  System  represents  a milestone 
in  the  Avionics  industry.  It  is  the  first  large  scale  applica- 
tion of  party  line  data  multiplexing.  The  critical  nature  of 
this  communication  makes  necessary  the  minimization  of  error.  To 
verify  that  the  data  error  rate  was  within  an  acceptable  limit 
both  data  bus  system  analysis  and  verification  tests  were  performed. 

SYSTEM  REQUIREMENTS 

All  communications  are  via  a fixed  word  structure  - a 3 wsec 
sync  field  followed  by  24  data  bits  and  a single  parity  bit.  The 
data  code  is  Manchester  II  (B1  ^-L)  per  MIL-STD-442  at  a bit  rate 
of  1 megabit  per  second.  The  sync  field  is  a nonvalid  Manchester 
code.  The  positive  and  negative  pulses  that  form  the  sync  are 
1.5  wsec  wide.  A command  word  sync  is  formed  by  a positive  pulse 
(1.5  usee  wide)  followed  by  a negative  pulse  (1.5  usee  wide)  and  a 
data  word  sync  is  formed  by  a negative  pulse  followed  by  a positive 
pulse. 

Figure  1 illustrates  a typical  Data  Bus  configuration.  Each 
host  LRU  contains  a Multiplexer  Interface  Adapter  (MIA)  for  data 
communication  over  the  data  bus.  The  MIA  provides  data  validation 

(error  chec)(ing)  logic  to  assure  that  the  received  word  conforms 

to  the  following  minimum  validation  criteria: 

a.  First  a valid  sync  field  must  be  received.  If  the  | 

sync  field  is  invalid  the  MIA  does  not  respond  to  i 

the  data  field.  \ 

b.  Each  bit  in  the  data  field  is  a valid  Manchester  II 
code.  If  any  bit  in  the  data  field  is  declared  in- 
valid a nonvalid  Manchester  error  flag  is  raised  (for 
use  by  the  Host  LRU) . 

c.  The  word  has  a minimum  of  24  data  bits  plus  parity. 

If  fewer  than  25  bits  are  received  a bit  count  error 
flag  is  raised. 

d.  The  parity  bit  renders  the  complete  25  bit  data  field 
"odd".  If  a parity  error  is  detected  a parity  flag 
is  raised. 

When  a word  received  by  a MIA  fails  to  conform  to  these 
criteria  the  word  is  considered  invalid  and  a detected  word  error 

(also  called  a bit  miss)  is  declared.  | 

! 

[ 
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Figure  2 illustrates  the  operation  of  the  SMIA  and  especially 
shows  the  error  signals  available  at  the  host  interface.  When 
the  host  receives  the  Rcvr  Bus  Active  signal  a valid  sync  has  been 
detected.  At  the  End  of  Word  strobe  the  user  interrogates  the 
error  signals  NV  Manchester,  Bit  Count  and  Parity  Error  to  verify 
error  free  detection  of  the  incoming  word. 

The  Space  Shuttle  Orbiter  requires  that  at  any  stub  the  Word 
Error  Rate  (WER)  be  3X10“^  or  better  (less)  when: 

a.  The  signal  amplitude  is  2 volts  peak. 

b.  The  noise  is  300  mv  RMS  white  Gaussian  distributed 
over  the  band  of  1000  hz  to  4 Mhz. 

c.  The  signal  rise  time  is  250  usee. 

The  WER  was  defined  to  be: 

Sync  Misses  + Bit  Misses  + Undetected  Bit  Errors 

WER  « Number  of  Words  Transmitted 

For  the  purpose  of  WER  performance  verification  a Sync  Miss 
is  defined  as  the  inability  to  declare  a valid  sync  (start  recep- 
tion) when  a valid  sync  is  )cnown  to  have  occurred  and  an  Undetected 
Bit  Error  is  defined  as  an  observed  error  in  any  bit  position  pro- 
vided that  a valid  sync  has  been  detected  and  a Bit  Miss  has  not 
occurred. 

Verification  of  this  performance  was  accomplished  by  both 
analysis  and  test. 

VERIFICATION  BY  ANALYSIS 

To  accomplish  this  by  analysis  it  required  that  we  develop: 

a.  Lumped  par2uneter  models  of  the  SMIA  in  both  the  transmit 
and  receive  modes  (see  Figures  3 & 4) 

b.  A lumped  parameter  model  of  the  Data  Bus  Coupler  (Figure 
5)  . 

c.  A model  of  the  SMIA  input  filter  (Figure  6) . 


d.  A lossy  transmission  line  model  representative  of  the 
cable  being  used.  By  measurement  of  various  lengths  of 
the  actual  Space  Shuttle  cable  the  model  illustrated  by 
Figure  9 was  derived. 


Use  of  these  models  enabled  the  analysis  of  the  total  data 
bus  system.  The  Space  Shuttle  mux  bus  configurations  were  re- 
viewed and  representative  configurations  were  analyzed  using 
Rockwell  supplied  input  signals.  This  analysis  determined  wave- 
form fidelity  and  WER  perform.ince  for  numerous  stub  locations  on 
several  bus  configurations. 

The  WER  Simulation  Table  (Table  I)  summarizes  the  range 
of  variance,  used  for  the  WER  analysis,  for  the  input  signal  am- 
plitude, the  input  noise,  the  signal  rise  time, the  SMIA  threshold 
voltage,  w the  SMIA  filter  bandwidth. 

To  get  a measure  of  the  affects  of  measurement  error  the  in- 
put signal  amplitude  was  allowed  to  vary  by  +3.5%  and  the  input 
noise  (RMS  value)  was  allowed  to  vary  by  +5%. 

The  WER  was  computed  for  all  of  the  above  conditions  and 
the  results  are  shown  in  Figures  10-20. 

Waveform  fidelity  was  determined  by  simulation  of  the  various 
bus  configurations.  The  results  were  later  verified  by  tests  on 
the  identical  bus  configurations.  Figures  21,  22  and  23  are  repre- 
sentative of  the  results  obtained  by  this  simulation.  The  insert 
in  these  figures  is  the  waveform  obtained  during  test  of  the  iden- 
tical bus  configuration. 

VERIFICATION  BY  TEST 

To  verify  the  computer  simulation  results  special  test  equip- 
ment was  developed  to  simulate  both  normal  and  abnoxmal  data  bus 
operation.  Tests  were  run  to  determine: 

a.  Effects  of  noise  on  bus  operation. 

b.  Effects  of  data  bus  lengths,  stub  lengths,  stub  locations, 
lino  discontinuities,  etc.  and  to  verify  performance 

such  as: 

c.  Distortion  tolerance.  ^ 

d.  WER 

e.  Design  margin. 

f.  Negative  test  limits 

g.  Environmental  effects. 


A 


WER  SIMULATION  - TABLE  I 


PARAMETERS  RANGE  OF  VARIANCES 


SIGNAL  S: 

1.5 

1.75, 

2.0, 

'2.0  VOLTS 

NOISE  N: 

VARIOUS 

MV 

RISE  TIME 

t^:  20.8, 

124.8, 

249.6 

NS 

THRESHOLD 

VOLTAGE  V^:170, 

190, 

210 

MV 

FILTER  BANDWIDTH  BW:  MIN 

NOM 

MAX 

SIGNAL  OFFSET:  -50  TO  100  MV 

WORD  PATTERN:  ALL  I'S,  ALTERNATING  I'S  AND  O'S 

SYNC : COMMAND , DATA 


To  perform  these  tests  the  test  configuration  illustrated 
by  Figure  24  was  assembled.  Since  the  noise  generator  provides 
very  wide  band  (20  Mhz)  white  noise  it  was  necessary  to  shape 
the  noise  spectrum  to  within  specification  limits  (1  kl:z  to 
4 Mhz)  prior  to  mixing  with  the  signal.  This  was  accomplished 
with  mixer  shown  in  Figure  25.  This  unit  has  the  capability  to 
process  the  input  signal  either  shaped  or  unshaped  prior  to 
mixing  with  the  band  limited  noise.  When  the  shaped  signal  is 
desired  the  signal  rise  time  amplitude  symmetry  and  peak-peak 
amplitude  are  individually  controllable. 

Table  II  summarizes  the  capability  of  this  Data  Bus  System 
Test  System. 

To  establish  confidence  in  both  the  comviuter  simulations 
and  in  the  Data  Bus  System  test  results  whenever  possible  results 
were  cross  checked.  Figure  26  shows  tlie  close  correlation  acliieved 
between  the  computer  simulation  and  the  test  results  for  WER  as 
a function  of  S/N. 

Table  III  summarizes  some  of  the  tests  conducted  during  t tie 
Data  Bus  System  evaluation  program.  These  tests  were  run  on 
several  different  bus  configurations. 

Typical  of  the  Shuttle  bus  conf igurat ions  is  the  I.Bl  bus 
(Figure  26).  This  is  a bus  of  moderate  length  (146  ft',  has  6 
stubs  and  a 4 stub  cluster  at  one  end.  Tables  IV  to  VI 1 sunu'.iarize 
the  results  of  the  amplitude,  sync  field  symmetry  and  SMI  A clock 
frequency  limit  tests  and  tlie  negative  tests  pei  formed  witli  this 
bus  configuration. 


SUMKAB1 


This  program  has  revealed  that  there  are  many  factors  to 
consider  during  the  design  of  a data  bus  system.  Aside  from  the 
usual  considerations  for  voltage  variutions  and  temperature  varia- 
tion one  must  now  be  concerned  about  such  parameters  as  waveform 
asymmetry,  signal  rise  time  at  the  receiving  unit,  wave  ^shape 
distortion  and  wave  shape  offset. 

All  of  these  adversely  impact  the  system  WER  performance. 

For  a 2.5V  pk  signal  (at  the  receiving  MIA)  the  parameter  variation 
impact  on  WER  is: 

. Bit  Asymmetry  (S5%)  - 1 Order  of  Magnitude 

. Threshold  Voltage  - ^ Order  of  Magnitude 

. Filter  Bandwidth  - H Order  of  Magnitude 

. Power  Supply  Variation  - Affects  threshold  voltage  (>  filter 

bandwidth 

. Input  Rise  Time  - A factor  of  2 around  nominal  of 

150  ii^sec 


. Wave  Shape  Distortion  - 2-3  Orders  of  Magnitude  for 

extreme  distortion 

. DC  Offset  - At  150  mv  noise,  2.6  V signal,  a 

25  mv  DC  offset  results  in  a S 
Order  of  Magnitude  degradation 

. Temperature  - 1 Order  of  Magnitude  from  -30®C 

to  +92°C 

The  above  WER  impacts  are  for  the  Space  Shuttle  Data  Bus 
System  configured  with  Singer  MIA's  - other  multiplexer  designs 
would  have  to  be  separately  analyzed  to  detennine  their  parameter 
variation  impact  on  WER. 

From  the  analysis  and  data  generated  during  this  program  it 
has  been  determined  that  the  Singer  MIA's  satisfy  the  Space  Shuttle 
Data  Bus  performance  requirements. 


DATA  BUS  SYSTEM  TEST  SET  CAPABILITY 


TABLE  II 


MODES  OF  OPERATION 


ERROR  TESTING 


O ECHO 


o WORD  COUNT 


O NORMAL 


o MISS  COUNT 


WORD  RATE  CAPABILITY 


o BIT  COUNT 


O MAX  RATE  (3  wSEC  WORD  GAP) 
O I KHz  RATE 


O OTHER  VIA  EXTERNAL  STIMULUS 


DATA  WORD 


O FIXED  (MANUAL  INPUT) 
o VARIABLE  (PSEUDO  RANDOM) 


o DATA  SAMPLING 
VALIDATION 

O 3 MIA  SIMULTANEOUS  TEST 

o NOISE  GENERATOR  EXTERNAL 
TO  DBS  T/S 

HOST  LRU  (ADJUNCT  TO  DBS  T/S) 
O MIA 


LIMIT  TESTING  (DATA  BUS  SIGNAL) 


o SYNC  FIELD 


O DATA  BIT 


O DATA  RATE  (VIA  EXTERNAL  STIMULUS) 


O OUTPUT  SIGNAL  LEVEL 


O LOGIC  FOR  ECHO  MOPE 
OPERATION  (DB  I/O) 

o STORAGE  AND  BUFFERS  FOR 
NRZ  OUTPUT  TO  T/S 
(DB  IN/NA2  OUT) 

o BUFFERED  CONTROL  SIGNAL 
I/O  INTERFACE 


NEGATIVE  TESTING 


O DROPPED  BIT 


O EXTRA  BIT 


O PARITY 


O INTERRUPTED  TRANSMISSION 


DATA  BUS  SYSTEM  EVALUATION  TESTS 
TABLE  III 


TABLE  V.  LIMIT  TEST,  SYNC  FIELD  SYMMETRY 


V 00 
O O O 
O O O 

o o o 

z z 2: 
\ w 

(0  (0  CO 

H II  n 

iH  <N  fO 


XXX 


TABLE  VI.  LIMIT  TEST,  DATA  FIELD  SYMMETRY 

SMIA  #1  = S/N  0002 

SMIA  #2  = S/N  0004 

SMIA  #3  = S/N  0008  (NS) 
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AIRCRAFT  MULTIPLEX  SYSTEM  DESIGN  AND  INTEGRATION 
REQUIREMENTS  FOR  LOW  NOISE  DATA  BUS  OPERATION 


By  William  S.  Hermann  and  Dr.  Clifford  D.  Skouby 
McDonnell  Aircraft  Company,  St.  Louis,  Mo. 


ABSTRACT 


This  paper  describes  the  importance  of  noise 
reduction  in  operational  aircraft  multiplex  systems. 

A number  of  noise  sources  such  as  intersymbol 
interference,  white  qaussian,  impulse,  common-mode, 
harmonic,  and  synchronization  noise  are  discussed. 

In  each  case,  methods  of  noise  reduction  are  reconmiended. 
The  effects  of  noise  on  bit  error  rate  is  illustrated 
for  distortion-free  as  well  as  distortion-limited 
perfoniiance.  Finally,  techniques  for  evaluatinq  data 
bus  perfoniiance  are  described  includinq  undetected 
error  rate  verification  and  eye  pattern  measurements. 


AIRCRAFT  MULTIPLEX  SYSTEM  DESIGN  AND  INTEGRATION 
REQUIREMENTS  FOR  LOW  NOISE  DATA  BUS  OPERATION 


By  William  S.  Hermann  and  Dr.  Clifford  D.  Skouby 
McDonnell  Aircraft  Company,  St.  Louis,  Mo 


INTRODUCTION 


This  paper  describes  various  system  design  and  integration  techniques 
for  low  noise  bus  operation  in  a typical  fighter  aircraft  environment. 

Major  sources  of  noise  and  signal  distortion  which  reduce  signal  detection 
capability  and  increase  bit-error  rates  will  be  discussed.  Also  tech- 
niques for  noise  reduction  and  signal  distortion  improvement  are  described 
for  applications  where  stub  effects,  cable  faults  and  non-linear  lines 
must  be  tolerated.  Since  data  bus  characteristics  can  be  minimized  by 
control  of  noise,  signal  waveforms  and  coupling,  the  critical  problems  of 
installation  can  be  minimized.  For  example,  a non-linear  bus  can  increase 
the  level  of  intersymbol  interference  caused  by  overlapping  of  pulse  tails 
in  successive  pulses.  Also,  wideband,  distributed  (Gaussian)  noise  and 
high  amplitude  impulse  noise  can  be  coupled  into  the  data  bus,  particularly 
if  common  mode  rejection  is  not  effective.  Harmonic  noise  generated  by 
high  rise-time  transmitted  waveforms  are  generally  a problem  with  radiated 
signal  effects  coupled  into  high  gain  R.F.  receivers  external  to  the  MUX 
system.  They  are  also  a source  of  intersymbol  interference  produced  by 
the  undamped  overshoots  in  each  bit  resulting  from  excessive  rise  and  fall 
times.  In  each  of  the  descriptions  of  noise  source,  specific  methods  of 
noise  reduction  are  recommended. 

SYSTEM  REQUIREMENTS 
FOR  LOW  NOISE  DATA  BUS  OPERATION 


NOISE  SOURCES  IN  BASEBAND  WIRE  LINE  MULTIPLEX 

• INTERSYMBOL  INTERFERENCE 

• WHITE  GAUSSIAN  AND  IMPULSE  NOISE 

• COMMON  MODE  NOISE 

• HARMONIC  NOISE 

• SYNCHRONIZATION  NOISE 
DATA  BUS  PERFORMANCE  vs  NOISE 

• SNR  vs  BER 

• EYE  PATTERNS 
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Finally,  techniques  for  determining  the  influence  of  noise  on  system 
performance  are  described  showing  the  relation  of  modulation  type  and 
noise  level  on  bit  error  rate.  Also,  the  use  of  eye  patterns  illustrate 
a technique  for  determining  system  margin  against  noise  error  at  the  best 
sampling  point.  Also,  they  provide  an  index  of  the  sensitivity  to  timing 
error  and  permit  the  evaluation  of  error  rate  limits  versus  eye  opening 
in  a long  train  of  random  pulses. 

INTERSYMBOL  INTERFERENCE 

Intersymbol  interference  is  the  most  common  source  of  distortion  and 
increased  error  rate  at  megabit  rates  in  wireline  data  bus  systems.  This 
waveform  distortion  is  produced  by  the  pul se-to-pul se  phase/ ampl itude 
overlap  of  the  pulse  tail  or  decay  transient  of  a proceeding  pulse  into  a 
successive  time  slot.  This  effect  is  particularly  a source  of  bit  error 
at  the  end  of  each  word  where  the  pulse  tail  from  the  last  bit  is  no 
longer  overlapped  by  a following  bit.  Consequently,  the  pulse  tail  energy 
is  sufficient  to  produce  an  additional  bit  detection,  producing  an  invalid 
bit  count. 

INTERSYMBOL  INTERFERENCE 

DESCRIPTION 

• ADJACENT  TIME  SLOT  OVERLAP  OF 

PRECEDING  PULSE  TAIL  WITH  EXISTING  PULSE 

SEVERITY 

• PRIMARY  SOURCE  OF  DISTORTION/BIT  ERROR 

CAUSE 

• PHASE/AMPLITUOE  NON-LINEARITY  OF  BUS 

TEST  CRITERIA 

• FOR  ZERO  INTERFERENCE  (NYQUISTI 

- EQUAL  ZERO  CROSSINGS  WITH  •T"  SECOND  PERIOD 
PRODUCE  CONSTANT  BIT  RATE  OF  l/T  SECONDS 

- EQUAL  PERIODS  BETWEEN  TRANSITIONS 

SOLUTION 

• CONTROLLED  TRANSMIT  RISE/FALL  TIME  (TRANSIENT  SUPPRESSION) 

• CONTROLLED  TRANSMIT  DECAY  (LINE  COUPLING-OROOPI 

• FILTERED  RECEIVER  INPUT  WAVEFORM 

• LIMITED  OPEN-LINE  FAILURE  MODES 

• LIMITED  NUMBER/LENGTH  OF  LONG  STUBS 
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It  should  be  noted  that  the  magnitude  of  waveform  distortion  is 
important  as  it  affects  the  value  of  each  pulse  at  the  sampling  instant 
since  bit  detection  and  detection  error  are  determined  at  this  point. 

In  "Data  Transmission"  by  Bennett  and  Davey,  the  probability  of  bit  error 
is  determined  for  a polar,  random,  binary  sequence  in  an  additive  white 
gaussian  noise  with  optimum  receiver  filtering.  The  point  in  this  case 
is  that  noise  induced  distortion  is  based  on  known,  statistical  distri- 
butions in  order  to  define  detection  performance.  This  assumes  a 
predictable  influence  of  a uniformly  distributed  noise  spectrum  and 
constant  amplitude  in  order  to  establish  the  influence  on  pulse  values 
at  the  sampling  instant.  Conversely,  Nyquist  defined  the  waveform 
criteria  for  an  "ideal  channel"  with  zero  interference  as  follows:  First, 
the  waveform  zero  crossings  must  be  equally  spaced  in  time  having  period 
of  "T"  seconds  and  a uniform  bit  rate  of  1/T  seconds.  Secondly,  the 
period  between  transitions  must  be  equal,  producing  symmetry  about  the 
zero  amplitude  axis.  This  effect  will  be  illustrated  in  later  discussion 
of  eye  pattern  tests. 

One  way  to  meet  the  Nyquist  criteria  is  to  filter  and  attenuate  all 
previous  pulse  effects  to  zero.  This  filter  response  can  be  achieved  by 
a sin  X/X  impulse  response  but  is  quite  sensitive  to  sampling  times  and 
requires  an  ideal  phase  versus  frequency  characteristic.  Consequently, 
it  is  better  to  examine  the  cause  and  effect  produced  by  non-ideal  but 
less  complex  solutions. 

The  basic  cause  of  intersymbol  interference  is  due  to  the  non-linear- 
ity of  the  data  bus  versus  frequency  resulting  in  exponentially  decaying 
transients  occurring  in  a subsequent  time  slot.  In  other  words,  a purely 
resistive  transmission  line  would  have  zero  transient  response.  Never- 
the  less,  an  attempt  to  produce  a resistive  or  zero  reactance  line  is 
unrealistic  in  practical  applications.  Instead,  a more  practical 
solution  is  to  avoid  non-linear  bus  configurations  insofar  as  practical 
plus  control  of  the  transmitted  and  received  waveform  distortion  and 
thirdly,  to  minimize  coupling  of  external  noise.  As  a matter  of  priority, 
the  bus  linearity  deserves  major  consideration  since  the  effects  of  inter- 
symbol interference  or  line  induced  channel  distortion  has  a considerably 
greater  impact  on  system  performance  than  noise  induced  distortion. 

Techniques  to  reduce  bus  non-linearity  include  minimal  use  of  stubing, 
using  terminal -to-terminal  party  line  termination  often  referred  to  as  a 
"daisy  chain".  Also,  open  circuit  faults  have  a devastating  effect  on  bus 
linearity  particularly  when  occuring  at  the  remote  terminal  connection  to 
a long  stub.  A latter  discussion  of  common-mode  noise  describes  the 
effective  use  of  grounded  center  taps  to  provide  an  impedance  path  to 
ground  in  the  event  an  open  occurs  in  one  conductor  of  the  bus. 

Techniques  to  control  waveform  distortion  include  the  use  of  sine 
wave  line  drivers  to  reduce  harmonics  injected  on  the  transmission  line 
and  receiver  filters  to  reduce  distortion  at  the  detector.  Digital 
matched  filters  using  active  element  CCD  devices  offer  a possible  solution, 
in  conjunction  with  LSI  microcircuit  technology.  Also  a single  chip  LSI 
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device  has  been  developed  to  perform  automatic  digital  equalization  as 
described  by  Gerst  and  Diamond  in  "Proc  IRE"  Vol  53,  July  1961.  This 
technique  was  popularized  by  the  audio  amplifier  designers  as  a method 
of  achieving  flat  response  from  frequency  sensitive  transducers.  An 
important  consideration  in  control  of  distortion  of  the  transmitted 
waveform  involves  the  design  characteristics  of  the  driver-to-1 ine 
coupling  transformer.  In  order  to  drive  the  line  specified  by  1553 
without  excessive  waveform  droop,  it  is  necessary  to  have  a sufficient 
time  constant  or  stored  energy  in  the  driver  transformer  to  sustain  the 
signal  level  for  all  bus  loading  conditions.  Or,  simply  stated,  the 
transformer  must  have  adequate  low  frequency  response  under  load.  Con- 
sequently, a minimum  primary  inductance  of  6.3  millihenries  is  recommended 
to  sustain  the  signal  level  within  voltage  limits  over  the  pulse  period. 

Techniques  to  minimize  coupling  of  external  noise  include  balanced, 
twisted  pair  transmission  line  with  transfonner  coupling  such  as 
described  by  MIL-STD-1 5538.  Also,  the  use  of  a grounded,  center-tapped 
coupling  as  described  previously,  provides  substantial  reduction  in 
conmon  mode  noise  in  non-faulted  mode  by  equalizing  the  balance  in  either 
line  to  ground. 

WHITE  GAUSSIAN  AND  IMPULSE  NOISE 

Line  induced  noise  is  a secondary  source  of  interference  which  has 
considerably  less  impact  on  detection  error  rates.  This,  of  course, 
assumes  that  reasonable  precautions  are  taken  such  as  shielding,  loading, 
grounding,  decoupling  and  filtering.  In  addition,  1553  calls  out  trans- 
former line  coupling  and  balanced,  shielded,  twisted-pair  transmission 
line  as  well  as  biphase  signaling  to  minimize  the  influence  of  external 
noise  on  data  bus  performance.  .Assuming  that  such  precautions  have  been 
taken,  it  is  nevertheless  desirable  to  predict  the  probability  of 
detection  error  as  related  to  expected  levels  of  signal  and  noise.  Since 
detection  probability  or  error  probability  is  related  to  the  noise  power 
within  a specific  bandwidth  required  for  signaling,  it  is  convenient  to 
specify  average  noise  power  with  a bandwidth  equal  to  the  data  rate. 

White  gaussian  noise  is  particularly  useful  as  a standard  definition  in 
which  the  total  average  noise  power  is  proporational  to  bandwidth.  It 
should  be  noted  that  noise  in  the  Nyquist  bandwidth,  is  also  frequently 
used  to  define  a noise  power  of  -3dB  less  than  noise  defined  in  the  bit 
rate  bandwidth.  Gaussian  noise  provides  a convenient  means  of  defining 
a density  and  distribution  for  noise  spectrums  within  the  detection  band- 
width. As  previously  described,  detection  thresholds  occur  at  the 
sampling  point  when  the  signal  value  exceeds  the  noise  level  by  a pre- 
determined value.  This  reference  can  be  defined  in  a number  of  compari- 
sons such  as  average  signal  power  for  a random  pulse  train  or  alternately 
for  a given  signaling  sequence.  Since  this  siunal  to  noise  relationship 
is  essential  to  determining  error  probability  at  the  sampling  instant, 
specific  conditions  must  be  established.  In  Bennett  and  Davey  on  "Data 
Transmission",  this  analysis  was  determined  for  a polar,  random,  binary 
sequence  with  raised-cosine  waveform  with  optimum  receiver  filtering 
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COMPARISON  OF  QAUSSIAN  vs  IMPULSE  NOISE 


WHITE  QAUSSIAN  IMPULSE  NOISE 


and  additive  white  gaussian  noise.  The  probability  of  error  for  this 
condition  is: 


^ 1 - erf  (2  E/No)^/^ 


where  E is  the  average  signal  output  power  received  and  No  is  the  average 
noise  power  in  the  bandwidth  equal  to  the  signaling  frequency.  This 
detector  performance  in  a given  signal -to-noi se  environment  requires  an 
excess  signal  above  the  detection  threshold  at  the  sampling  instant  as 
previously  discussed.  The  gaussian  noise  distribution  permits  statistical 
prediction  of  power  levels  at  the  instantaneous  point  of  sampling.  Never- 
theless gaussian  noise  is  ideal  in  the  sense  that  both  amplitude  peaks, 
spectral  bandwidth  and  energy  distribution  are  not  representative  of 
typical  aircraft  interference.  From  a practical  point  of  view,  impulse 
noise  having  either  random  or  periodic  impulse  duration,  frequency  of 
occurance  and  burst  interval  more  typically  represent  chattering  relays, 
or  switching  currents  in  data  bus  subscriber  pairs.  Relay  noise  is 
generally  characteristic  of  a short  burst  interval  of  a few  miliseconds 
duration  or  less  in  periodic  or  randomly  spaced  groups.  In  order  to 
analytically  model  this  type  noise,  it  is  necessary  to  have  a statistical 
description  of  the  pulse  amplitudes,  pulse  durations  and  pulse  time 
occurances  and  distribution.  The  solution  will  typically  take  the  form 
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of  Poisson  shot  noise  model  in  which  the  random  area  (a  i)  of  an  impulse 
occurs  at  the  random  time  instant  ti  in  any  observation  interval  of  To 
seconds. 


N{t)  = ^ di  A (t  - ti ) 
i = 

Since  the  noise  model  requires  specific  knowledge  of  the  probability  of 
distribution  of  the  pulses  in  time,  amplitude  and  occurrence,  it  is  more 
convenient  to  evaluate  the  system  noise  susceptabi 1 i ty  in  a test  laboratory. 
Consequently,  a typical  transformer  coupled  data  bus  with  shielded,  twisted 
pair  transmission  line  was  evaluated  in  the  presence  of  impulse  noise  with 
various  bus  grounding  and  shielding  configurations.  These  test  results 
are  illustrated  in  the  next  paragraph  on  common  mode  noise. 

COMMON  MODE  NOISE 

The  benefits  of  balanced  pair  transmission  are  well  recognized  as 
a means  of  reducing  common  mode  noise  prevalent  in  unbalanced  or  ground 
return  type  transmission  lines.  Consequently,  MIL-STD-1553  has  specified 
balanced,  twisted  pair  transmission  lines  in  order  to  reduce  the  effects 
of  common-mode  noise  coupling.  This  noise  is  coupled  into  a line  to 
ground  signal  due  to  noise  currents  developing  a voltage  across  finite 
resistance  paths  to  ground  which  appear  in  series  with  the  legitimate 
signal  to  ground  path.  In  contrast,  methods  of  controlling  common  mode 
noise  in  a balanced  line  are  not  as  well  recognized.  One  argument  is 
that  no  ground  reference  exists  in  a balanced  line,  consequently  the 
problem  is  non-existent.  A second  argument  is  that  use  of  a single  ground 
reference  does  not  permit  a ground  circulating  current.  Both  of  these 
viewpoints  fail  to  recognize  that:  first,  there  is  a capacitive  coupling 
to  ground  from  each  signal  line  in  the  balanced  pair  to  the  shield  which 
is  grounded  to  avoid  electrostatic  coupling.  Secondly,  the  ground 
coupling  is  not  to  a single  point  since  the  capacitive  effects  are 
distributed  over  a wide  variety  of  ground  points  therefore  circulating 
currents  will  be  produced.  Also,  the  total  capacitive  effects  from  each 
line  to  ground  are  not  equal  consequently  voltage  unbalance  and  circulating 
currents  to  ground  occur  which  increase  common  mode  noise  in  the  balanced 
signal . 

To  minimize  this  noise,  it  is  necessary  to  minimize  the  unbalance. 

That  is  to  say,  if  the  unbalance  to  ground  is  zero,  then  the  conmon  mode 
coupling  is  zero.  To  accomplish  this  in  a relatively  simple  manner,  the 
centertap  of  the  line  driver  transformer  and  each  line  receiver  trans- 
former should  be  grounded  as  illustrated.  It  is  important  to  emphasize 
that  the  centertap  balance  can  be  controlled  to  relatively  high  degree 
of  accuracy  within  fractions  of  a percent  unbalance.  In  contrast,  the 
nominal  line  to  shield  capacitance  of  47  picofarads  per  foot  can  vary 
as  much  as  ten  to  twenty  percent  from  each  line  to  shield  producing 
relatively  high  levels  of  unbalance  and  conmon  mode  noise.  The  simpli- 
fied circuit  illustrates  the  necessity  for  grounding  the  centertaps  at 
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BALANCED  LINE  COUPLING 


Eli  * El2  ■ El3  * El4  for  ideal  center  tap 
Eli  • El3  * El2  ■ El4  a o within  ct  balance  ERRDR 

E^  - INSTANTANEOUS  COMMON  MODE  NOISE  VOLTAGE  DEVELOPED  ACROSS 
THE  GROUND  PATH  RESISTANCE 


both  ends  of  the  bus.  If  a perfect  balance  occurs,  then  Eli , El2»  El3, 
and  El4  are  equal  consequently  the  centertap  potential  of  both  trans- 
formers are  equal  and  zero  common  mode  voltage  is  developed  in  the 
coupling  transformers.  If  either  zero  or  one  centertap  is  grounded,  the 
capacitance  to  ground  produces  a considerably  higher  unbalance  and 
considerable  increase  in  common  mode  noise  coupling  results. 

Several  additional  observations  can  be  made  from  the  grounded  center- 
tap  circuit.  First,  the  ground  path  carries  only  the  unbalance  current 
and  not  the  signal  current.  Consequently,  the  integrity  of  the  ground, 
or  the  resistance  of  the  path  does  not  have  a significant  effect  on  the 
signal  or  the  common  mode  rejection  capability.  Secondly,  if  a catastro- 
phic failure  or  open  occurs  in  one  line,  the  second  line  will  operate  as 
an  unbalanced,  1 ine-to-ground,  transmission  line,  with  additional  common 
mode  noise  but  with  a total  functional  capability. 

It  is  recognized  that  the  simplified  equivalent  circuit  does  not 
include  all  the  actual  circuit  elements  such  as  transformer  winding 
resistance,  winding  capacitance,  leakage  capacitance,  mutual  coupling, 
transmission  line  resistance,  etc.  As  can  be  seen  from  the  illustration, 
the  detailed  equivalent  circuit  adds  considerably  to  the  task  of  circuit 
analysis.  Also  the  additional  detail  has  a negligible  influence  on  the 
effects  of  unbalance  on  common  mode  noise  rejection  with  the  exception 
that  capacitive  coupling  from  primary  to  secondary  (line  to  terminal) 
provides  an  unbalance  to  ground  if  the  terminal  is  an  unbalanced,  grounded 
configuration.  To  minimize  the  primary  to  secondary  capacitive  coupling, 
the  use  of  an  electrostatic  shield  is  strongly  recommended. 
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LUMPED  CIRCUIT  EQUIVALENT 
BALANCED  LINE  DATA  BUS 


The  results  of  laboratory  tests  verify  the  postulated  performance  of 
a balanced  pair  transmission  line  to  reduce  common  mode  noise  using 
grounded,  center  tapped  coupling  for  both  the  transmitter  and  receiver.  In 
the  illustrated  test,  a 55  foot  shielded  twisted  pair  was  inductively 
coupled  to  an  impulse  noise  source  of  60  volts  and  0.5  microsecond  pulse- 
width.  As  can  be  seen  from  the  waveforms  to  the  lower  left  of  the 
illustration,  a peak  noise  signal  of  3.2,  2.0,  and  2.8  volts  was  induced 
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PRELIMINARY  NOISE  INTERFERENCE  STUDY  LINE  PICKUP 
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while  minimizing  the  steep  wavefront  condition.  Some  caution  should  be 
observed  in  control  of  detector  sampling  time;  however,  to  avoid  reduction 
in  signal  margin  above  threshold,  as  described  in  the  next  paragraph  on 
synchronization. 

SYNCHRONIZATION  NOISE 

Synchronization  noise  creates  zero  crossing  deviations  in  timing  due 
to  phase  distortion  in  the  waveform.  In  the  case  of  an  asynchronous  data 
bus  such  as  1553,  timing  can  be  derived  from  an  internal  high  frequency 
clock,  usually  12  or  16  MHz,  referenced  to  the  invalid  sync  code  or  from 
a reconstructed  clock  derived  from  the  data.  For  random  noise  occurance, 
the  probability  of  error  is  less  in  the  former  since  distortion  must  occur 
in  the  3 bit  sync  code  interval  in  order  to  produce  timing  deviation.  The 
1553  standard  permits  a maximum  zero  crossing  deviation  of  25  nanoseconds 
or  five  percent  of  the  bit  interval.  This  timing  error  will  cause  devianon 
from  the  optimum  sampling  point  irrespective  of  other  distortion  in  the 
bit  waveform.  The  shift  from  optimum  sampling  will  result  in  reduced 
detection  margin  above  threshold  for  both  sinusoidal  and  trapezoidal  wave- 
forms, assuming  a permissable  ten  percent  droop  in  the  latter  case.  For 
the  sinusoidal  case,  the  amplitude  reduction  to  99.69  percent  of  optimum 
results  with  a zero  crossing  deviation  of  25  nanoseconds.  For  the  trape- 
zoidal case,  the  amplitude  reduction  is  0.99667  percent  of  optimum  with 
25  nanoseconds  crossing  deviation,  100  nanoseconds  rise/fall  time  and 
10  percent  droop.  In  both  cases,  this  represents  a 0.05  dB  loss  in  signal - 
to-noise  ratio  and  negligible  change  in  bit  error  rate  of  the  system. 
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corresponding  respectively  to  the  first  test  with  ungrounded  shield  and 
open  centertaps  on  both  coupling  transformers,  the  second  test  with 
ungrounded  shield  and  only  the  transmitter  centertap  grounded,  and  thirdly, 
the  ungrounded  shield  and  only  the  receiver  centertap  grounded.  It  should 
be  noted  that  in  this  group  of  tests,  the  noise  pickup  was  relatively  high, 
i.e.,  in  excess  of  2 volts  and  in  no  case  were  both  centertaps  grounded. 

In  the  second  group  of  tests,  illustrated  on  the  lower  right,  a peak  noise 
signal  of  0.4,  0.5,  and  0.6  volts  was  induced  corresponding  respectively 
to  test  number  four  with  both  centertaps  grounded  and  shield  not  connected, 
test  number  five  with  both  centertaps  grounded  and  shield  grounded  at  trans- 
mitter, and  test  number  six  with  both  centertaps  grounded  and  shield  grounded 
at  both  ends.  It  should  be  noted  that  the  noise  pickup  voltages  are  relatively 
low  in  this  group  of  tests,  i.e.,  approximately  0.5  volts  and  in  all  cases 
both  centertaps  were  grounded.  In  other  words,  the  centertaps  are  effective 
in  reducing  common  mode  noise  by  a factor  of  six  to  one  when  grounded  at 
both  the  transmitter  and  receiver. 

HARMONIC  NOISE 

McDonnell  Aircraft  specifications  for  line  driver  waveform  for  the  F-15 
aircraft  (MCAIR  specification  H-009)  and  for  the  F-18  aircraft  (MCAIR  specifi- 
cation A- 38188)  limit  the  harmonic  output  of  the  line  driver  to  essentially  a 
sine  wave.  This  is  in  contrast  to  a number  of  system  integrators  who  permit 
a square  wave  or  more  accurately  a trapezoid  with  limited  rise  time  and 
limited  droop.  It  is  well  to  use  a reference  to  "Data  Transmission"  by 
Bennett  and  Davey  which  states  that  except  for  the  waste  of  transmitted 
power,  it  is  immaterial  what  the  curve  for  the  transmitting  filter  (wave- 
form harmonic  content)  is  like  for  frequencies  above  the  bit  rate  if  the 
receiving  filter  has  no  response  at  these  frequencies.  This  criteria  is 
intended  to  apply  only  to  multiplex  receiver  response  and  disregards  other 
receivers  on  the  aircraft.  Since  a number  of  communications,  navigation, 

IFF  and  ECM  receivers  have  sensitivities  of  one  or  two  microvolts  into 
50  ohms  input  impedance,  the  harmonics  of  a 10  volt  (zero-to-peak)  data  bus 
driver  output  can  represent  a relatively  high  power  interference  within  the 
passband.  Admittedly,  the  radiated  harmonics  of  the  data  bus  driver  can 
be  limited  by  shielding  nevertheless  suppression  of  interference  begins 
with  reduction  of  transmitted  harmonics  where  practical.  MCAIR  has  produced 
more  than  350  F-15  aircraft  to  date  and  experienced  no  difficulty  with  data 
bus  radiation  problems.  We  believe  that  sine  wave  driver  outputs  are  a 
commonsense  approach  to  radiation  reduction.  This  requires  a more  costly 
linear  amplifier  driver  but  represents  a good  investment  in  RFI  suppression. 

A second,  but  equally  important  consideration,  is  the  transient  response 
of  a sine  wave  versus  a quasi  square  wave  to  a reactive  load.  The  pulse 
tail  produced  in  the  latter  case  is  contributor  to  intersymbol  interference 
as  described  previously.  Since  this  interference  is  the  primary  cause  of 
detector  bit  errors,  every  effort  should  be  made  to  reduce  the  pulse  tail 
distortion.  Revision  B to  MIL-STD-1553  permits  a range  of  rise  and  fall 
times  from  a minimum  of  100  nanoseconds  to  a maximum  of  300  nanoseconds 
when  measured  from  10  percent  to  90  percent  of  the  peak  to  peak  value. 

The  sinusoidal  rise  and  fall  time  of  295  nanoseconds  meets  this  criteria 
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A second  caus.  of  deviation  from  mid-point  sampling  is  not  related  to 
'’oise  effects  but  nevertheless  produces  a similar  shift  in  sampling  point. 
Conseouently  it  is  a source  of  reduction  in  amplitude  at  the  sampling 
point  and  hence  loss  of  detection  margin.  This  deviation  in  sampling  is 
caused  by  the  resolution  or  granularity  of  timing  produced  by  the  12  or 
16  MHz  clock.  Since  the  leading  edge  of  a clock  pulse  which  is  most 
nearly  coincident  with  the  mid-point  of  the  bit  period  is  used  for  timing, 
a finite  shift  in  sampling  point  results  from  the  random  difference  in 
coincidence.  Obviously,  a 12  MHz  clock  will  have  a more  course  granularity 
and  consequently  a greater  reduction  in  detection  margin.  Since  coin- 
cidence is  limited  to  one  half  of  one  clock  period  maximum,  the  12  MHz 
clock  could  have  a lack  of  mid-point  coincidence  by  as  much  as  40  nano- 
seconds. This  worst  case  clock  deviation  is  the  same  magnitude  of  error 
as  in  the  zero  crossing  deviation  error  and  hence  has  a relatively  minor 
influence  on  bus  performance. 


BIT  ERROR  RATE  VS  SIGNAL  TO  NOISE  RATIO 


In  the  previous  discussion  of  gaussian  and  impulse  noise,  the_ computa- 
tion of  bit  error  probability  versus  signal-to-noise  ratio  (SNR)  was  shown 
in  a non-quantitative  example.  In  this  illustration,  the  actual  effect  of 
SNR  on  system  performance  in  terms  of  bit-error-rate  (BER)  is  shown.  The 
curve  on  the  left  shows  the  BER  versus  SNR  for  distortion-free,  "synchro- 
nous", biphase  signaling  while  the  center  curve  shows  a slightly  reduced 
performance  for  distortion-free,  "asynchronous",  biphase  signaling.  The 
curve  on  the  right  shows  the  performance  with  a 6dB  degradation  from  the 
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distortion-free,  asynchronous  detector  to  allow  a practical  level  of  wave- 
foitn  distortion  such  as  trapezoidal  waveshape  with  droop,  oon-sviumetrica  1 
zero  crossing  and  sync  distortion.  Other  noise  effects  are  analytically 
compensated  for  as  a function  of  SNR  with  the  exception  that  the  distortion- 
free  oerformance  is  based  on  gaussian  noise.  In  contrast  the  practical 
curve  includes  a margin  for  the  effects  of  impulse  noise. 

It  should  be  noted  that  the  "B"  revision  (1553)  performance  require- 
ment of  10"'  BER  at  a 17.5  dB  SNR  appears  on  the  distortion-limited  perfor- 
mance curve.  This  value  of  SNR  was  intentionally  selected, to  produce  a 
corresponding  value  of  BER  which  is  sufficiently  high  (10“'')  to  permit  test 
and  performance  verification  within  a reasonable  1;ime  period.  In  contrast, 
the  original  1553  performance  requirement  of  lO"'*-  BER  at  14dB  required 
considerable  test  time  to  verify.  By  adding  more  noise,  the  detector  per- 
formance can  be  determined  at  a higher  BER  point  on  the  curve  with  substan- 
tially less  test  time  required. 

The  verification  of  detector  performance  in  terms  of  BER  should  consider 
the  measurement  of  both  detected  and  undetected  errors.  To  measure  unde- 
tected errors  which  do  not  correlate  with  the  transmitted  signal  and  are  not 
detected  by  the  terminal  under  test,  it  is  necessary  to  compare  the  trans- 
mitted and  received  signals  on  a bit-to-bit  basis.  It  is  also  important  to 
have  an  accurate  reference  of  the  transmitted  data  for  comparison  with  the 
detected  data  from  the  terminal  under  test.  To  achieve  a highly  accurate 
transmitted  data  reference,  the  data  bus  should  be  a low  noise  type  with 
typical  SNR  of  21  dB.  This  is  generally  not  a problem,  since  the  bus  length 
and  linearity  can  be  controlled  in  a laboratory  tost  configuration.  Since 
this  transmitted  data  reference  has  a theoritical  error  rate  gf  10"''*  at 
21  dB,  it  becomes  an  infinitely  accurate  reference  to  the  10"'  error  rate 
system  under  test.  To  verify  detector  performance,  the  noise  output  mixed 
with  the  test  signal  should  be  increased  to  produce  17.5  dB  SNR  and  the 
correlated  transmi t/recei ve  error-rate  determined. 

UNDETECTED  ERROR  VERIFICATION 


UNDETECTtD  BER  - 10*’^ 
21  dB  SNR 
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EYE  PATTERNS 


Eye  patterns,  so-called  for  their  resemblance  to  a human  eye,  are  a 
useful  laboratory  method  of  evaluating  random  interference  effects  in  a 
long  pulse  train.  By  observing  an  oscilloscope,  with  horizontal  sweep 
externally  synchronized  to  the  bit  rate,  the  bits  can  be  superimposed  over 
the  same  sweep  Interval.  This  overlapping  effect,  allows  the  observer  to 
evaluate  intersymbol  interference  in  terms  of  the  vertical  and  horizontal 
eye  openings.  For  example,  the  vertical  opening  corresponds  to  the  sampling 
point;  and  the  horizontal  opening,  to  the  transition  in  the  bit  period. 
Consequently,  variations  in  the  horizontal  pattern  result  from  variation  in 
bit  transition  time.  A perfect  eye  pattern,  corresponding  to  a distortion 
free  signal,  has  maximum  eye  opening  and  conforms  to  the  Nyquist  criteria 
for  zero  intersymbol  interference  described  earlier.  The  ratio  of  the  mea- 
sured eye  opening,  produced  by  the  overlapping  patterns  with  random  distor- 
tion, as  compared  to  the  maximum  opening,  indicates  the  limits  in  waveform 
distortion.  Also  the  patterns  are  quite  useful  in  determining  the  optinum 
sampling  point  where  the  eye  is  open  widest  and  in  observing  the  effects  of 
zero  crossing  deviation.  As  pointed  out  by  Lucky,  Salz  and  Weldon  in 
"Principles  of  Data  Communications",  the  sensitivity  of  the  system  to  timing 
can  be  observed  as  the  sampling  time  is  varied  and  the  signal  distortion 
limits  appear  as  a vertical  width  or  closure  at  the  sampling  point.  As  this 
text  further  points  out,  this  degree  of  opening  can  be  used  to  bound  the 
probability  of  error  if  the  noise  distribution  is  known.  Typically,  an  eye 
opening  of  0.5  might  be  used  as  measure  of  reliable  data  transmission. 
Nevertheless  it  is  not  a direct  measure  of  bit-error-rate  as  described 
previously  and  should  not  be  considered  a substitute  for  BER  verification 
tests.  It  is  however  useful  In  determing  the  minimum  margin  in  a given  data 
sequence,  particularly  a random  sequence,  where  the  varying  overlap  can  be 
constantly  monitored. 

EYE  PATTERN  EFFECTS  vs  DISTORTION 
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SUMMARY 


In  summary,  a number  of  noise  sources  have  been  described  briefly,  as 
well  as  some  of  the  causes  and  cures.  The  best  approach  to  high  perfor- 
mance data  bus  integration  is  noise  prevention  and  test  verification.  After 
the  fact  cures  are  expensive  and  often  ineffective  when  cable  routing,  cou- 
pling, grounding  and  shielding  must  be  reconfigured  throughout  the  system. 
Keep  in  mind  that  intersymbol  interference  is  a major  source  of  increased 
error  rate  and  that  the  most  common  cause  is  non-linearity  of  the  trahs- 
mission  line.  Particular  emphasis  should  be  given  to  reduction  in  stub 
lengths  insofar  as  possible.  Also,  externally  induced  noise  and  waveform 
distortion  should  be  minimized  by  balanced  line-to-ground  coupling  and  low 
harmonic  distortion  waveforms. 
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MULTIPLEX  DATA  BUS  APPLICATIONS  IN  AIRCRAFT  SIMULATORS 


Chris  G.  Horattas 


Goodyear  Aerospace  Corporation 
Defense  Systems  Division 
1210  Massillon  Road,  Akron,  Ohio  4A315 


ABSTRACT 

This  paper  describes  an  adaptation  of  certain  airborne  aircraft 
systems  to  a ground  based  aircraft  simulator  by  duplicating  or  emulating 
the  aircraft  multiplex  bus.  The  considerations  that  led  to  such  adaptation, 
the  problems  that  arise  and  the  means  by  which  they  may  be  resolved  are  dis- 
cussed. 

A special  data  bus  controller  that  makes  the  use  of  on-board  aircraft 
equipment  in  a simulator,  without  modifications  to  the  hardware  or  software 
is  described. 

A specially  designed  multiplex  data  bus  for  simulator  applications  is 
also  discussed. 

INTRODUCTION 

Current  Air  Force  simulator  procurements  require  that  operational  flight 
programs  developed  specifically  for  the  airborne  computer,  be  capable  of  being 
used  in  the  simulator  without  modifications;  furthermore,  that  changes  to  such 
programs  necessitated  by  aircraft  updates,  be  capable  of  being  Incorporated  into 
the  simulator,  affecting  its  operation  in  the  same  way  such  changes  affect  air- 
craft operation. 

To  meet  these  requirements,  simulator  manufacturers  resorted  to  emulators 
for  the  on-board  flight  computers,  or  to  the  actual  use  of  the  on-board  com- 
puters in  the  simulator.  Other  aircraft  systems,  particularly  the  tactical 
displays,  have  grown  in  complexity,  so  that  their  simulation  can  best  be  achieved 
by  using  actual  aircraft  systems.  These  aircraft  equlpment>  when  used  In  the 
slnoulator,  must  be  Interconnected  exactly  as  if  they  were  in  the  aircraft.  Thusi 
the  aircraft  multiplex  data  bus  must  be  transplanted  to  the  ground  based  simulator. 
It  would  seem  like  a relatively  simple  matter  to  purchase  the  on-board  computer 
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with  its  operational  software,  the  aircraft  equipment  and  an  aircraft  multi- 
plex data  bus.  Interconnect  them  and  produce  a simulator.  It  would  also  be 
easy  to  conclude  that  the  simulator  manufacturer's  data  bus  problems  have  been 
solved  by  the  airframe  manufacturer. 

Unfortunately,  the  requirement  of  using  on-board  equipment  In  simulators 
does  not  always  work  In  the  direction  of  simplifying  the  simulation  task. 

Sometimes  It  solves  one  problem  at  the  expense  of  creating  another.  How,  for 
example,  would  unmodified  airborne  equipment  by  physically  Interfaced  with 
simulated  aircraft  equipment?  Are  signals  electrically  compatible?  How  will 
timing  and  synchronization  be  accomplished? 

By  far  the  majority  of  the  systems  used  In  the  aircraft  are  simulated  In 
the  aircraft  simulator.  Black  boxes  and  active  control  panels  may  be  replaced 
by  facsimiles,  that  only  resemble  their  aircraft  counterparts.  The  aircraft 
operational  software  requires  that  all  peripheral  devices,  normally  connected 
to  the  data  bus,  be  connected  and  operating.  This  requirement  must  be  met, 
whether  such  software  Is  Installed  In  an  aircraft,  or  In  a simulator.  Control 
words  generated  by  the  on-board  computer  must  be  accepted  and  responses  generated 
by  all  equipment  connected  to  the  bus. 

Those  devices  that  normally  are  connected  to  the  aircraft  bus,  but  omitted 
In  the  simulator,  are  designated  as  "ghost"  devices.  A special  purpose  controller 
designated  as  Ghost  Devices  Controller  (GDC)  Is  designed  to  provide  the  necessary 
responses  to  the  bus  controller  In  lieu  of  the  "ghost"  devices.  This  controller 
Is  discussed  In  great  dhtall  In  this  paper. 

In  addition  to  the  transplanted  airborne  equipment  and  aircraft  bus,  there 
exists  In  the  simulator  a number  of  simulated  systems,  that  consist  of  modified 
hardware  and  special  software  modules,  which  together  create  the  effects  that 
the  real  aircraft  systems  would  produce.  A specially  designed  bus  that  Inter- 
connects these  simulated  systems,  designated  as  Simulator  Data  Bus  (SDB) , Is 
also  covered  In  this  paper. 

GENERAL  BACKGROUND  ON  SIMULATION 

Since  this  paper  Is  primarily  concerned  with  multiplexed  data  buses  per- 
taining to  aircraft  simulators.  It  Is  considered  appropriate  to  describe.  In 
general  terms,  a typical  aircraft  simulator. 


Figure  1 Is  a simplified  block  diagram  of  a typical  aircraft  simulator. 
Identifying  Its  major  components.  An  aircraft  simulator  consists  mainly  of 
four  major  components.  They  are:  1)  the  trainee  station,  2)  the  Instructor 
station,  3)  the  computation  system  and,  4)  the  environment  simulation  complex. 
Each  of  the  four  components  are  discussed  as  follows: 

1)  The  trainee  station.  The  trainee  station  consists  primarily  of  a cock 
pit,  which  resembles  the  cocxplt  of  the  simulated  aircraft  down  to  Its  most  min' 
ute  detail.  This  Is  the  station  at  which  a pilot  trainee  will  gain  familiarity 
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with  the  aircraft  and  acquire  skills  in  flying  and  operating  the  real  aircraft. 
It  is  essential^  therefore,  that  all  controls  and  Indicators  in  ttie  simulator 
cockpit,  including  visual  and  aural  displays,  function  exactly  as  they  would  in 
the  actual  aircraft,  llie  trainee  must  derive  the  same  sense  and  feel  from  the 
simulator  cockpit,  as  he  would  from  the  actual  aircraft  cockpit.  The  trainee 
station  may  be  mounted  on  a platform,  that  can  provide  up  to  six  degrees  of 
motion  - three  in  translation  and  three  in  rotation. 


Some  of  the  panels  and  black  boxes  Installed  in  the  trainee  station  cock- 
pit are  actual  aircraft  components,  imong  these  components  could  be  the  radar 
display,  the  Heads-Up  Display  (HUD)  and  the  Horizontal  Situation  Indicator  (HSI) . 
Other  aircraft  systems  installed  in  the  simulator  may  only  consist  of  front 
panels,  which  contain  various  controls  and  indicators.  The  electronics  asso- 
ciated with  these  panels  and  black  boxes  are  replaced  with  program  modules 
operating  within  a simulation  computer. 

These  program  modules  receive  cues  from  pilot  controls  and  provide  corre- 
sponding indications,  which  are  analogous  to  the  effects  of  these  cues  on  the 
aircraft  aerodynamic  characteristics.  An  example  of  such  device  is  the  navi- 
gation control  and  indicator  panel. 

2)  The  instructor  station.  The  instructor  station  consists  of  a console, 
on  which  all  controls  and  indicators  within  the  cockpit  are  repeated,  so  as  to 
allow  an  instructor  to  monitor  and  evaluate  the  trainee's  actions.  A set  of 
special  controls  allow  the  instructor  to  preset  or  alter  parameters  of  a train- 
ing mission,  e.g.  to  initialize  a training  mission,  to  freeze  the  problem,  and 
to  inject  failures.  An  inter-communication  system  also  exists,  wttictt  allows 
the  instructor  to  communicate  with  the  trainee  by  voice. 

3)  The  computation  complex.  The  computation  complex  consists  of  all 
simulation  computers  and  related  peripherals.  The  on-board  computer  and  the 
Ghost  Device  Controller,  discussed  in  this  paper,  arc  part  of  the  computation 
system.  All  trainee  and  all  instructor  actions  produce  cues  to  tlie  simulation 
programs  within  the  computation  system.  Outputs  from  these  programs  are  used 
to  drive  actuators,  or  activate  Indicators  and  displays  at  both  stations. 

4)  The  simulation  complex.  The  simulation  complex  comprises  all  hardware 
required  to  provide  realistic  effects,  wliich  enhance  the  simulation.  Aural  tones, 
synthetic  targets  generation,  feel  forces  and  cockpit  motion,  are  some  of  the 
outputs  of  the  simulation  hardware  complex. 

It  should  be  apparent  by  now  that  a sinnilator,  in  addition  to  simulating 
the  aerodynamics  of  the  aircraft,  must  also  simulate  the  environment.  Ground 
and  airborne  active  emitters,  visual  scenes,  and  ground  radar  returns  are  but 
a few  of  the  environmental  requirements  in  the  simulator.  These  combined  re- 
quirements create  an  enormous  data  traffic  on  the  data  bus  at  near  real  time 
speeds. 
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THE  GHOST  DEVICES  CONTROLLER 


1.  General.  The  Ghost  Devices  Controller  (GDC)  is  a specially  designed 
device,  which  is  connected  to  the  aircraft  multiplex  bus  to  compensate  for  all 
"ghost"  devices.  "Ghost"  devices  are  those  devices  that  are  normally  connected 
to  the  bus  within  the  aircraft,  but  are  not  necessary  in  the  simulator  environ- 
ment. The  GDC  is  programmed  to  respond  to  all  control  words  directed  by  the 
airborne  computer  to  the  "ghost"  devices.  It  will  accept  or  supply  data  and 
status  words  peculiar  to  the  "ghost"  devices,  wlille  it  appears  transparent  to 
the  on-board  computer  and  its  operational  flight  program.  Figure  2 is  a block 
diagram,  which  compares  the  airborne  multiplex  data  bus  to  the  same  bus  in  the 
simulator.  The  position  of  the  GDC  in  relation  to  other  devices  on  the  bus  is 
shown  in  Figure  2B. 

The  GDC  also  provides  a data  link  between  the  on-board  computer  and  the 
simulation  computer  complex. 

2.  GDC  Description.  The  GDC  contains  driving  and  receiving  capability 
which  is  compatible  with  the  aircraft  multiplex  data  bus.  This  compatibility 

is  prescribed  by  the  specification  that  governs  all  devices,  wttich  are  connected 
to  the  aircraft  multiplex  data  bus. 

The  GDC  is  programmed  to  receive  all  control  words  emanating  from  the  on- 
board computer.  For  control  words  Intended  for  one  of  the  "ghost"  devices,  the 
GDC  assumes  an  active  role.  It  accepts,  or  furnishes,  data  and  control  words 
depending  on  the  mode  of  operation.  For  control  words  to  devices  physically- 
connected  to  the  bus,  the  GDC  assumes  a passive  role.  It  eavesdrops  on  the 
bus,  monitoring  and  storing  control,  status  and  data  words  for  subsequent 
transfer  to  the  simulation  computer. 

Finally,  the  GDC  has  the  capability  of  assuming  the  role  of  a bus  con- 
troller in  a back-up  mode.  This  occurs  wltenever  the  on-board  computer  loses 
control  of  the  multiplex  data  bus. 

3.  GDC  Operation.  The  operation  ol  the  GDC  depends  on  the  mode  of  opera- 
tion of  the  bus.  For  this  discussion,  it  is  assumed  tlint  the  multiplex  data 
bus  conforms  to  MIL-STD-1553.  MIL- .STD- 1553  requires  that  the  airborne  computer 
issues  a control  word,  which  contains  a terminal  address  field,  a subaddress 
field,  a transmit /receive  bit  (T/R) , a word  count  field  and  a parity  bit. 

The  GDC  receives  all  control  word.*  and  data  words,  wliich  appear  on  tlie 
multiplex  bus,  in  a receiver  register.  This  register  is  a serial  in  parallel 
out  register.  The  terminal  address  and  subaddress  fields  and  the  T/K  bit  arc 
used  as  an  address  to  a read  only  memory  (ROM).  Tlie  output  of  the  ROM  is  a 
vector  address  to  a read/write  memory  (RAM).  The  vector  address  point.,  to 
the  first  address  of  a block  of  addresses  defined  as  a data  bufler.  The 
buffer  consists  of  an  address,  witere  the  control  word  is  stored.  The  second 
address  In  the  buffer  may  be  the  source  of  a status  word,  or  the  destination 
of  the  first  word  of  data,  depending  on  the  mode  of  operation. 

Several  modes  of  operation  prescribed  by  MIL-STD-1553  are  descrilvd  as 
follows : 


FIGURE  2.  AIRCRAFT  SYSTEMS  IN  THE  SIMULATOR 


a)  The  airborne  computer  transmits  data  to  a connected  device,  b)  the  airborne 
computer  requests  data  from  a connected  device,  c)  the  airborne  computer  trans- 
mits data  to  a "ghost"  device,  d)  the  airborne  computer  requests  data  from  a 
"ghost"  device,  e)  the  airborne  computer  commands  one  connected  device  to  trans- 
mit data  to  another  "ghost"  device  and  g)  the  airborne  computer  conmiunds  Inter- 
conmunicatlon  betwen  a connected  device  and  a "ghost"  device.  The  operation 
of  the  GDC  for  each  of  these  modes  varies  slightly  as  described  in  the  following 
paragraphs  and  illustrated  on  Figure  3 for  each  mode. 

a)  Whenever  the  airborne  computer  commands  a connected  device  to  receive 
data,  the  GDC  stores  the  control  word  in  the  vector  address.  The  connected 
device  responds  with  a status  word,  which  the  GDC  stores  in  the  second  address 
relative  to  the  vector  address.  All  data  words  sent  by  the  airborne  computer 
to  the  device  are  received  by  the  GDC  and  stored  in  subsequent  RAM  addresses 
for  a later  transfer  to  the  simulation  computer. 

b)  Whenever  the  airborne  computer  conmands  a connected  device  to  supply 
data,  the  GDC  again  stores  the  control  word  in  the  vector  address;  the  trans- 
mitted data  are  received  by  the  GDC  and  stored  in  subsequent  addresses;  the 
status  word  generated  by  the  responder  device  Is  stored  in  the  last  word  of  the 
buffer  for  later  transfer  to  the  simulation  computer. 

c)  Whenever  the  airborne  computer  commands  a "ghost"  device  to  accept 
data,  the  vector  address  will  point  to  the  status  word  of  the  "ghost"  device, 
which  is  read  out  and  transmitted  first.  This  status  word  is  prestored  in  the 
GDC  RAM  by  the  simulation  computer.  Subsequent  data  emanating  from  the  air- 
borne computer  are  received  by  the  GDC  and  stored  in  subsequent  RAM  addresses. 

d)  Whenever  the  airborne  computer  commands  a "ghost"  device  to  supply 
data,  the  vector  address  will  point  to  the  first  of  a block  of  addresses  in 
the  GDC  RAM,  where  data  is  pre-stored  by  the  simulation  computer.  The  last 
word  transmitted,  which  is  the  last  word  in  the  block,  will  be  the  status  word. 
The  status  word  is  also  preset  by  the  simulation  computer  into  the  GDC  RAM. 

e)  Whenever  the  airborne  computer  commands  one  connected  device  to  trans- 
mit data  to  another  connected  device,  the  GDC  eavesdrops  on  the  bus  and  stores 
the  computer  control  word  to  the  receiver  device  and  the  receiver  device's 
status  word  in  the  first  two  vector  addresses.  The  computer  control  word  to 
the  transmitter  device  is  stored  in  the  third  word,  and  the  data  are  stored  in 
subsequent  words,  followed  by  the  status  word  of  the  transmitting  device. 

f)  Whenever  the  airborne  computer  commands  one  "ghost"  device  to  transmit 
data  to  another,  the  two  control  words  are  received  and  stored  by  the  GDC,  but 
only  status  words  will  be  generated  by  the  GDC  to  the  bus.  Tlte  vector  address 
of  the  "ghost"  device,  that  will  receive  data,  points  to  the  RAM  address  wliere 
the  first  control  word  is  stored,  followed  by  the  receiver  ghost  devices  status 
word,  which  is  transmitted  first.  The  second  control  word  will  provide  the 
vector  to  where  the  second  control  word  is  stored,  followed  by  the  status  word 
of  the  transmitting  "ghost"  device,  which  is  sent  to  the  bus  next.  No  data 
transfers  are  required  in  this  mode. 
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ADDRESS 

CONTENT 

REMARKS 

VA 

CONTROL  WORD 

VA+l 

DEVICE  STATUS  WORD 

AIRBORNE  COMPUTER 

VA+2 

FIRST  DATA  WORD 

COMMANDS  A CONNECTED 

1 

DEVICE  TO  RECEIVE 

1 

1 

DATA  (GDC  PASSIVE) 

VA+WC+2 

LAST  DATA  WORD 

VA 

CONTROL  WORD 

AIRBORNE  COMPiri'ER 

VA+l 

FIRST  DATA  WORD 

COMMANDS  A CONNECTED 

1 

1 

DEVICE  TO  TRANSMIT 

I 

i 

DATA  (GDC  PASSIVE) 

VA+WC+l 

LAST  DATA  WORD 

VA+We+2 

DEVICE  STATUS  WORD 

VA 

CONTROL  WORD 

VA+l 

GHOST  DEVICE 

AIRBORNE  COMPUTER 

STATUS  WORD 

COMMANDS  A GHOST 

VA+2 

FIRST  DATA  WORD 

DEVICE  TO  RECEIVE 

1 

1 

1 

1 

DATA  (GDC  ACTIVE) 

VA+WC+2 

{ 

LAST  DATA  WOilD 

VA 

CONTROL  WORD 

VA+L 

FIRST  DATA  WORD 

1 

1 

AIRBORNE  COMPiri'ER 

1 

1 

COMMANDS  A GHOST 

1 

DEVICE  TO  TRANSMIT 

VA+WC+l 

LAST  DATA  WORD 

DATA  (GDC  ACTIVE) 

VA+WC+2 

GHOST  DEVICE 

STATUS  WORD 

VA 

CONTROL  WORD  TO 

RECEIVE  DEVICE 

VA+l 

RECEIVER  DEVICE 

STATUS  WORD 

VA+2 

CONTROL  WORD  TO 

AIRBORNE  COMPUTER 

TRANSMITTER  DEVICE 

COMMANDS  ONE  CONNECTED 

VA+3 

FIRST  DATA  WORD 

DEVICE  TO  RECEIVE 

1 

1 

AND  ANOTHER  TO  TRANSMIT 

1 

1 

1 

(GDC  PASSIVE) 

VA+WC+3 

LAST  DATA  WORD 

VA+WCM-A 

TRANSMITTER  DEVICE 

STATUS  WORD 

VA 

CONTROL  WORD  TO  RE- 

VA+l 

CEIVER  GHOST  DEVICE 

AIRB0!1NE  COMPUTER 

VA+2 

RECEIVER  GHOST  DEVICE 

COMMANDS  ONE  GHOST 

STATUS  WORD 

DEVICE  TO  TRANSMIT 

VA+3 

CONTROL  WORD  TO  TRANS- 

DATA  TO  ANOTHER 

MITTER  GHOST  DEVICE 

GHOST  DEVICE 

VA+4 

TRANSMITTER  GHOST 

(GDC  ACTIVE) 

1 

» 

DEVICE  STATUS  WORD 

NOTE:  VA  DENOTES  VECTOR  ADDRESS 
WC  DENOTES  WORD  COUNT 

FIfiURE  3 - GDC  RAM  MEMORY  MAP 
742 


A 


g)  VIhenever  the  airborne  computer  coomands  one  connected  device  to 
comnunicate  with  a "ghost"  device,  or  conversely,  the  receiving  device  will 
supply  Its  status  word  before  the  data.  The  transmitting  device  will  supply 
Its  status  word  after  the  data.  The  GDC  operates  similar  to  previously  de- 
scribed modes,  by  ordering  the  control  words,  status  words  and  data  words  In 
memory  so  as  to  follow  the  sequence  specified  by  the  bus  convention. 

Figure  4 is  a block  diagram  illustrating  the  GDC  logic.  The  receiver  register 
output  after  a control  word  is  received,  will  consist  of  the  unit  address, 
subaddress  and  T/R  bit.  This  output  forms  the  address  to  the  RCM.  The  output 
of  the  RC»1  is  the  vector  address  to  the  RAM  which  is  preloaded  into  a memory 
address  register  (MAR).  As  data  is  received,  or  transmitted,  the  MAR  is  in- 
cremented and  the  word  counter  is  decremented.  The  end  of  transmission  will 
occur  when  the  word  count  reaches  zero. 

4.  Simulation  Computer  Interface.  The  simulation  computer  interface 
to  the  GDC  is  similar  to  the  interface  between  the  ROM  and  RAM.  A parallel 
address  is  received  from  the  computer  channel,  which  accesses  directly  the 
RAM  memory  (DMA),  to  preset  data  and  status  words,  or  to  sample  incoming  data 
and  status  words.  This  interface  is  interlocked  with  the  multiplex  data  bus 
in  order  to  prevent  interference  with  ensuing  transmissions. 

A second  DMA  interface  from  the  simulation  computer  may  be  provided,  which 
connects  to  the  airborne  computer  Ground  Support  Equipment  (GSE)  port.  This 
port  allows  loading  and  verifying  functions  to  the  airborne  computer.  During 
operation,  the  simulation  computer  can  gain  direct  control  over  the  airborne 
computer  to  simulate  mission  freeze,  initialize  or  fall  by  using  the  GSE  port 
interface. 

5.  Timing.  In  accordance  with  the  MIL- STD-1553,  data  and  status  words 
must  be  obtained  in  the  three  microsecond  SYNC  time.  Even  though  this  time 
is  adequate  for  accessing  the  RAM,  an  additional  six  microseconds  could  be 
provided  by  employing  a buffer  register.  At  shift  count  11,  the  terminal  address, 
subaddress  and  T/R  bit  are  available  in  the  receiver  register  and  they  could  be 
transferred  in  parallel  to  the  buffer  register.  While  the  word  count  and  parity 
bits  are  being  shifted,  the  vector  address  is  pipelined  to  the  RAM  and  the  re- 
sponse word  is  in  the  Transit  register  even  before  the  entire  control  word  is 
received. 

To  assure  that  data  between  the  airborne  computer  and  the  simulation 
computer  propagate  throughout  the  trainer  in  the  same  program  cycle,  the  DMA 
interface  between  the  simulation  computer  and  the  GDC  is  done  twice  during 
the  cycle  time  of  the  airborne  computer. 

SIMULATOR  MULTIPLEX  DATA  BUS 

To  acconnodate  the  enormous  data  traffic  between  the  computation  system 
and  the  simulation  hardware,  a second  multiplex  data  bus  has  been  incorporated 
in  the  simulator.  This  bus  differs  from  the  airborne  multiplex  data  bus  in 
that,  it  can  accommodate  devices  of  dissimilar  word  formats.  Unlike  the  air- 
borne bus  which  consists  of  a single  data  line,  the  simulator  multiplex  data 
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FIGURE  4 - GHOST  DEVICES  CONTROLLER  FUNCTIONAL  DIAGRAM 
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bus  consists  of  the  data  line,  a synchronizing  shift  clock,  a data  envelope 
and  a command  indicator  pulse.  The  four  signals  transmission  lines  consist 
of  twisted  pairs  driven  by  tristate  bus  drivers.  Due  to  the  fact  that  the 
clock  is  distributed  to  the  various  simulated  devices,  encoding  into  a bi- 
phase code  such  as  the  Manchester  Code  is  not  necessary.  Incorporating  en- 
coding and  decoding  electronics  into  each  device  connected  to  the  bus  would 
be  unwieldly,  especially  if  the  device  is  a single  board. 

The  simulation  multiplex  data  bus  described  has  two  main  features:  1) 
it  reduces  the  multitude  of  interconnecting  cabling  by  its  distributed  I/O 
feature  and  2)  it  reduces  system  noise  and  power  requirements  by  its  address- 
ing structure. 

1)  Distributed  I/O.  The  distributed  1/0  scheme  allows  a set  of  data 
acquisition  modules  and  conversion  hardware  to  be  located  at  each  remote 
station.  Where  the  moving  platform  is  involved,  the  resulting  reduction  of 
cabling,  from  several  thousand  conductors  to  four  conductors,  is  a very 
desirable  aspect.  All  data  are  transferred  serially  by  bit,  serially  by  word 
between  the  two  stations  and  the  computation  system  on  the  simulator  multi- 
plex data  bus. 

2)  Addressing  Structure.  The  addressing  in  the  simulation  multiplex 
data  bus  is  so  designed  as  to  minimize  the  number  of  drivers  and  receivers 
that  can  be  active  at  the  same  time.  In  fact  a single  driver  and  a single 
receiver  can  be  enabled  at  one  time,  resulting  in  lower  power  dissipation 
and  lower  noise  generation  in  the  simulator. 

Because  of  the  serial  transmission  of  data,  several  other  features  re- 
sult: The  data  can  be  easily  formatted  into  words,  bytes  or  bit  groups  of 
any  predetermined  format,  thus  reducing  packing,  unpacking  and  bit  processing 
by  the  computer  I/O  programs,  as  well  as  making  interfacing  of  devices  of 
varying  bit  formats  possible.  Furthermore,  the  serial  data  transmission  scheme 
lends  Itself  to  ease  of  closed  loop  testing,  required  by  readiness  and  main- 
tenance tests. 

Figure  5 is  a block  diagram  that  Illustrates  the  Simulator  Multiplex  Data 
Bus.  Several  levels  of  addressing  are  provided.  At  the  computation  system,  a 
two-bit  address  could  select  one  of  four  stations,  with  which  communication  is 
desired.  A single  bit  can  establish  the  direction  of  data  flow.  Another  two 
bits  can  establish  one  of  four  groups  of  signals  (l.e..  Analog,  Discrete  Synchro, 
etc.).  Finally,  the  remaining  bits  can  decode  into  a device  address,  and  data 
word  count. 

BIT  PROCESSING 

Command  words  and  data  words  are  transferred  in  parallel  from  the  channel  to  an 
I/O  controller.  The  l/O  controller  serializes  the  data  onto  the  multiplex  bus. 
Bit  grouping  will  be  accomplished  within  the  l/O  controller  by  the  formatting 
logic.  The  formatting  logic  identifies  words  by  a pre- determined  sequence  and 
provides  variable  gates  to  tailor  each  transfer  to  the  bit  format  of  the  device 
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FIGURE  5 - SIMULATION  MULTIPLEX  DATA  BUS  BLOCK  DIAGRAM 


for  which  data  Is  Intended. 

Conversely,  data  originating  at  the  remote  devices  will  be  accepted  by 
the  l/O  controller  in  serial  format  and  converted  to  parallel  formats  of  vary- 
ing bit  lengths,  before  they  are  transferred  in  parallel  to  the  simulation 
computer. 

OPERATION 

The  multiplex  data  bus  is  synchronized  to  computer  handshake  signals  so 
as  to  make  external  storage  of  data  unnecessary.  Conmands  are  identified  by 
a Command  indicator  handshake  signal.  The  Command  words  may  contain  the 
initial  device  address,  the  number  of  words  to  be  transferred,  the  direction 
of  data  flow  and  a station  sub-address. 

Either  of  two  modes  of  transmission  could  be  selected.  1)  The  sequential 
mode,  and  2}  the  random  address  mode.  In  the  sequential  mode  one  coiranand  word 
precedes  a block  of  several  words.  Devices  are  programmed  by  decoding  an  in- 
cremented address  generator  located  at  each  station.  Only  one  device  can  be 
connected  to  the  multiplex  bus  at  one  instant.  This  mode  requires  that  all 
devices  be  updated  for  each  CPU  l/O  cycle.  In  the  random  mode,  a command 
word  must  be  generated  for  each  data  transfer.  The  throughput  of  the  bus 
appears  to  be  decreased  by  the  random  address  mode.  If  however  one  considers 
that  data  from  various  devices  may  change  less  frequently  than  others,  a 
combination  of  random  addressing  and  a sequential  addressing  could  be  devised 
that  provides  optimum  operation. 

CONCLUSION 

Multiplex  data  buses  in  simulators  have  been  successfully  utilized  with 
a great  number  of  advantages  realized.  The  roost  obvious  advantage  is  cabling 
reduction  due  to  multiplexing,  resulting  in  cost  savings,  reliability,  maintain- 
ability, ease  of  Installation  and  modifications.  Serial  data  multiplexing  adapts 
easily  to  on-line  and  off-line  teats  of  the  various  circuit  cards  within  the 
system  to  establish  system  integrity. 
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1553B;  HOW  DO  YOU  KNOW  YOU'LL  PASS  THE  NOISE  TEST? 


Robert  M.  Salter 


Sperry  Univac 


ABSTRACT 

1553B  requires  a figure  of  merit  to  be  met;  operation  in  200mv 
RMS  of  white  noise  with  word  error  rate  of  10~  or  better.  How 
does  one  reliably  run  this  test  in  a laboratory  and  how  does  one 
analyze  a given  design  for  noise  rejection?  The  laboratory  test 
requires  special  coupling  of  white  noise  onto  the  line  and  care 
in  connecting  monitor  equipment.  Analysis  ot  the  effect  of  noise 
requires  accounting  for  the  band  limit  of  4 MHZ  and  considering 
the  various  ways  in  which  noise  can  cause  a problem,  e.g.,  during 
rise  times,  peaks,  and  dead  times. 
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INTRODUCTION 


A new  error  rate  test  faces  the  designer  of  a MIL-STD- 
1553B  interface.  The  essence  of  the  test  for  a direct 
coupled  system  is: 

200mV  RMS  of  white  noise  bandwidth  IKHZ  to  4MHZ, 
shall  be  imposed  upon  a 3V  peak-to-peak  signal 
and  the  resultant  word  error  rate  shall  be  less 
than  1 in  10  words - 

1553A  does  not  require  this  figure  of  merit  but  instead 
uses  an  electromagnetic  interference  test  (MlL-STD-461 
and  462) . The  direct  noise  test  was  suggested  in  the  1976 
Proceedings  and  was  actually  required  for  the  B-1,  AMUX 
system  but  generally  this  will  be  new  territory  for  1553 
designers.  The  good  news  is  that  the  test  is  not  difficult 
to  pass.  The  bad  news  is  that  it  is  difficult  to  prove  you 
passed  it.  The  test  is  somewhat  difficult  to  set  up  pro- 
perly and  analysis  of  the  effect  of  noise  is  non-trivial. 

But  the  lab  testing  should  not  be  ignored  and  the  proper 
analysis  of  noise  effects  may  be  rewarding  (or  required) . 

So  this  paper  will  hopefully  give  you  a "leg  up"  on  both 
testing  and  analysis  of  noise.  It  is  not  really  a "How  To" 
manual  but  rather  a guide  to  what  to  be  aware  of . 

WHAT  IS  WHITE  NOISE? 

The  textbook  definition  of  white  noise  is  a signal  with 
an  equal  mix  of  all  frequencies,  randomly  phased.  Its  spec- 
trum therefore  is  flat  (Figure  lA) . In  the  time  domain  the 
noise  appears  as  "hash" . As  the  frequency  components  ran- 
domly add  and  subtract  the  signal  changes  amplitude,  oc- 
casionally achieving  large  values.  The  probability  of  a 
given  sample  exceeding  a given  level  is  derived  from  the 
Gaussian  or  Normal  probability  chart  (Figure  IB) . The  graph 
is  used  as  follows:  the  total  area  under  the  curve  is  unity. cr 

corresponds  to  the  RMS  value  of  the  white  noise  or  the 
standard  deviation.  If  cr"  = 200mV  the  probability  of  a given 
sample  exceeding  Iv  (5^  ) is  the,^shaded  area  of  Figure  lb. 

This  value  is  approximately  3x10  (see  Table  at  end  of  paper) . 
Three  samples  in  ten  million  exceed  Iv.  If  the  noise  band- 
width is  much  greater  than  the  sampling  rate  the  statistical 
correlation  is  zero,  so  t^a^  the  probability  of  two  consecu- 
tive Iv  samples  is  (3x10  ) . (For  high  sampling  rates  this 

is  not  true  as  will  be  seen  later) . 

PITFALLS  OF  LABORATORY  TESTING  OF  NOISE 

The  noise  test  is  not  difficult  to  pass.  Each  decoder 
design  is  immune  to  certain  noise  effects  and  the  rest  can 
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f(t)-WHITE  NOISE 


FIGURE  lA)  FREQUENCY  SPECTRUM  ^ WHITE  NOISE 


EXPANDED  SCALE 
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be  minimized  with  analog  or  digital  filters.  However,  to 
confirm  that  a new  design  is  free  of  unforeseen  flaws,  a 
laboratory  test  will  often  be  desirable.  Programming  the 
test  is  straightforward.  The  electrical  setup  as  not  tri- 
vial and  to  conduct  it  with  confidence  requires  attention 
to  three  areas;  noise  generation,  coupling,  and  monitoring 

Noise  Generation 


The  noise  generator  should  have  a flat  spectrum  from 
IKHZ  to  4MHZ.  Such  a generator  may  not  be  available.  (A 
commonly  available  generator  has  a 5MHZ  bandwidth,  for  ex- 
ample) . Either  a filter  must  be  devised  to  shape  the  band- 
pass or  the  test  must  be  adjusted  to  compensate  for  the 
"imperfection".  This  is  the  first  potential  problem: 

Pitfall  1:  If  the  noise  spectrum  is  not  a flat  IKHZ 
to  4MHZ,  be  prepared  to  prove  that  the  spectrum  used 
is  "worse",  that  it  causes  more  errors  than  an  ideal 
test . 

As  an  example,  if  a 5MHZ  bandpass  is  used,  ZOOmV  RMS  puts 
only  179mV  into  the  1KHZ-4MHZ  spectrum.  222mV  is  required 
to  get  the  proper  power  in  IKHZ  to  4MHZ.  Siii.ilarly,  if  your 
spectrum  is  not  flat  you  should  feel  obligated  to  prove  that 
this  defect  does  not  affect  test  validity. 

Once  the  noise  source  is  chosen  a wideband  amplifier  will 
likely  be  required  to  deliver  power  to  the  line.  An  impor- 
tant consideration  is  the  following; 

Pitfall  2;  The  amplifier  must  not  only  pass  the  4MHZ 
bandwidth  but  it  must  deliver  a minimum  peak  voltage, 
dependent  upon  the  coupler.  Noise  spikes  up  to  1.5v 
should  be  seen  by  the  receiver. 

White  noise  has  a boundless  voltage  range,  but  practically 
the  noise  generator  and  amplifier  clip  at  some  point.  (This 
point  is  obvious  if  the  noise  is  viewed  on  an  oscilloscope). 
Some  errors  are  a result  of  large  (lv-1.5v)  excursions  and 
this  amount  of  noise  should  appear  on  the  receiver  inputs. 

If  the  amplifier  clips  at  too  low  a voltage  some  remarkably 
low  error  rates  are  achievable. 

Coupling 

The  noise  must  be  superimposed  on  the  signal  with  a coupler. 
Direct  coupling  and  transformer  coupling  are  possible.  Figure  2 
shows  a general  direct  coupler.  The  amplifier  should  see  its 
specified  impedance  and  the  1553B  output  should  be  attenuated 
to  3v  peak-to-peak. 
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The  direct  coupler  has  the  following  characteristics: 


1.  Noise  is  attenuated,  requiring  the  amplifier 
to  have  a proportionally  higher  voltage  range. 

2.  Grounding  problems  are  likely  to  occur.  Directly 
coupling  equipment  to  a normally  floating  system 
introduces  conunon  mode  effects. 

A general  transformer  coupler  is  shown  in  Figure  3.  It 
has  the  following  characteristics: 

1.  Ground  problems  are  avoided. 

2.  The  noise  voltage  can  be  amplified  with  a step-up 
t ransformer . 

3.  The  transformers  tt'nd  to  act  as  filters,  perhaps 
limiting  the  bandpass. 

In  view  of  the  above: 

Pitfall  3:  Don't  expect  the  paper  design  of  a coupler 
to  be  sufficient.  Prepare  rather  to  break  off  ground 
prongs  or  rewind  t ransfoiiiiers  to  achieve  a non-distor- 
ting coupler. 

Monitoring 

Implicit  in  the  discussion  of  coupling  is  that  the  lino 
is  being  monitored  for  spectrum  integrity,  clipping,  and 
waveform  fidelity.  A true  RMS  meter,  spect  inim  analyzer, 
and  oscilloscope  are  necessary. 

Pitfall  4:  Your  monitoring  equipment  will  also  afli'ct 
your  system.  Watch  for  grounding  and  coupling  problems. 

The  above  covers  most  of  the  problems  likely  to  be  encount- 
ered in  the  laboratory.  If  the  pitfalls  are  avoided  you  will 
run  a convincing  test. 

WHITE  NOISE  THEORETICAL  ANALYSIS 

Why  Analyze? 

Some  reasons  for  analyzing  your  decoder  are  the  following: 

1.  It  may  bo  required  by  your  customer. 


2.  An  "imperfect"  laboratory  test  may  lequiie  some 
analysis  to  back  it  up. 
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A second  characteristic  of  the  bandlimited  noise  is  that 
the  distribution  of  energy  is  uniform  throughout  the  IK 
to  4MHZ  spectrum.  The  energy  is  proportional  to  the  square 
of  the  voltage  and  the  noise  can  be  considered,  for  example, 
as  4 IMHZ  wide  spectra  at  lOOmv  all  superimposed.  (Each 
IMHZ  lOOmv  band  would  deliver-lOmw  to  a 1 load  for  a total 
of  40mw,  which  equals  (200mv) ‘^/l -/T- ) . 

The  Effect  of  Noise  On  The  Decoder 

One  answer  to  this  is  "No  effect,  because  I have  this 
filter  out  front.."  The  filter,  however,  must  pass  500KHZ, 
IMHZ,  and  the  rise/fall  fairly  accurately  to  get  the  signal 
through,  and  some  noise  inevitably  passes.  Assume  that  the 
recei ver/decoder  sees  all  the  noise  and  consider  the  effects. 
Problems  that  noise  could  cause  include  the  following: 

1.  Pulse  stretching  and  shrinking. 

2.  Spurious  zero  crossings  during  peaks. 

3.  Envelope  glitching. 

4.  Voltage  reversal  during  rise/fall. 

For  each  an  approach  to  answering:  "What  is  the  probability 
of  this  occurring?"  is  given. 

Pulse  Stretching  and  Shrinking 

Consider  this  pulse  stretching  problem:  the  circuit  sets 
an  error  flag  if  the  first  half  sync  exceeds  2000ns  (nominal 
is  1500ns.)  What  is  the  probability  that  noise  will  stretch 
the  first  half  sync  of  transmission  500ns? 

Approach:  Tlie  noise  must  be  500ns  long  and  at  least 

0.5v  high  (to  trip  the  receiver).  The  noise  in  the 
IMHZ  to  4MHZ  band  is  a mix  of  sine  waves  with  half 
periods  less  than  500ns.  This  will  never  produce  a 
pulse  500ns  wide  (and  in  fact  will  make  wide  pulses 
less  likely).  The  pulse  will  be  caused  by  the  IKHZ 
to  IMHZ  band,  which  has  lOOmv  of  RMS  voltage.  This 
band  produces  a pulse  SOOmv  high  (5C7“)  with  probab- 
ility 3x10“^,  which  is  alarmingly  high. 

_7 

We  can  pause  here  and  note  that  3x10  represents  an  upper 
bound  on  the  probability  since  there  are  other  frequencies 
present.  But  the  designer,  from  this  quick  estimate,  is 
forced  to  investigate  further  the  susceptibility  of  his 
circuit  to  this  problem  (or  possibly  he  has  a filter  which 
knocks  out  low  frequencies,  in  which  case  he  knows  he  is  safe) , 


Spurious  Zt'ro  Crossing  During  Peak  Voltage 


Assume  the  circuit  fails  if  a noise  spike  drives  the 
signal  through  zero  in  the  middle  of  the  l.Svpeak.  What 
is  the  probability  of  this  happening? 

Approach;  The  noise  spike  must  exceed  -1.5v  which  is 
7 . 5 T This  has  probability  much,  much  less  than 
10“^®.  Even  with  a decoder  sample  rate  of  lOMHZ  (200 
samples  per  word)  the  chance  of  a word  having  this 
error  is  much  less  than  10“'.  Rest  easy. 

Envelope  Glitching 

Assume  the  circuit  has  an  envelope  detector  which  rises 
if  the  signal  exceeds  threshold  and  drops  if  the  signal  is 
between  thresholds  for  longer  than  200ns.  What  is  the  pro- 
bability that  noise  will  cause  a "glitch"  in  the  envelope? 

Approach ; A noise  spike  Iv  high  and  200ns  wide  could 
possibly  force  the  envelope  detector  to  drop.  Only 
frequencies  in  the  range  IKHZ  to  2.5MHZ  could  ever 
produce  a pulse  this  wide.  This  band  has  158mv  of 
noise  (62%  of  energy) . A sample  in  this  range  exceeds 
Iv  (6.20~)  with  probability  1 in  10^®.  Is  this  neg- 
ligible? No.  Assume  each  pulse  of  noise  is  200ns  wide. 
The  noise  typically  spends  200ns  above  a volt  and  lO^^x 
200ns  (2000  seconds)  below  a volt.  How  many  20us  words 
are  transmitted  in  2000  seconds?  Only  10®  which  means 
one  word  in  10®  could  have  an  envelope  glitch. 

While  this  is  an  upper  bound  and  seems  safe  the  calculation 
indicates  that  although  a given  event  has  low  probability 
the  word  error  rate  depends  on  how  susceptible  the  circuit 
is  to  the  error.  This  pulse  occurring  any  time  in  the  trans 
mission  could  cause  an  error  (unlike  the  pulse  stretching 
example) . 

Voltage  Reversal  During  Rise/Fall 

Assume  the  circuit  fails  if  a voltage  reversal  occurs 
during  a rise/fall  (Figure  5).  What  is  the  probability 
of  this  occurring? 

Approach;  Finding  a meaningful  upper  bound  here  is  very 
difficult  and  the  example  perhaps  reveals  the  limits  of 
analysis.  The  simplest  model  assumes  all  the  power  is 
at  4MHZ.  A pulse  of  only  0.6v  causes  a reversal  if  it 
occurs  during  a rise/fall  (15mv/ns  slew  rate  is  required) 
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Such  a pulse  (125ns  wide)  occurs  typically  once 
in  31us  and  even  considering  the  signal  is  rising 
or  falling  about  30%  of  the  time  a voltage  reversal 
occurs  in  roughly  one  of  five  words.  The  models  are 
clearly  too  crude.  The  lower  frequencies  affect 
probability  of  a given  slew  rate,  but  to  calculate 
the  result  of  all  the  combinations  of  frequencies  is 
a task  similar  to  deriving  the  Gaussian  distribution 
itself . 

It  is  better  here  to  ask  a new  question;  "Do  voltage  re- 
versals cause  any  problem?"  If  you  are  sampling  every  50ns 
a voltage  reversal  could  cause  a glitch,  (the  question  of 
probability  is  much  more  manageable  in  this  case) , but 
sampling  every  100ns  or  200ns  there  is  no  problem  at  all. 

The  last  example  notwithstanding,  it  is  possible  to  es- 
tablish meaningful  upper  bounds  on  the  probability  of  some 
important  errors  and  these  estimates  may  directly  influence 
filter  or  logic  design.  There  are  other  effects  not  covered 
here,  such  as  "Does  the  circuit  hang  up  if  a spurious  half 
sync  appears  on  a dead  line?  How  probable  is  this?",  or 
"Will  noise  keep  the  envelope  detect  always  active?  Will 
this  cause  errors?"  Each  circuit  has  its  own  susceptibil- 
ities and  by  asking  the  appropriate  question,  and  finding 
how  much  of  what  frequency  noise  is  relevant,  these  suscep- 
tibilities can  be  understood. 


759 


<N  ^ ID 


appkndix 


short  Table  of  Probabi  1 i t.  i ps 


P(V  > nCr"  ) 


0 

1 


. 18 


0.5 

0.159 

0.023 

0.0014 

3.2x10 


-5 


2.9x10 

3.2x10 


-10 


Derived  from  Reference  Data  For 
5th  Edition,  p.  45 
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AN  OPTICAL-FIBRE  MULTI-TERMINAL 


DATA  SYSTEM  FOR  AIRCRAFT 
J.G.  Farrington 

Standard  Teleconununication  Laboratories  Limited 
London  Road,  Harlow,  Essex,  CM17  9NA,  Essex 


A demonstration  optical  fibre  multi-terminal  data  bus 
system  has  been  constructed.  The  system  has  no  central 
controller,  and  can  use  any  number  of  terminals  up  to  the 
designed  maximum.  The  system  has  been  arranged  to  operate 
with  a wide  range  of  optical  harness  layouts. 

1 . INTRODUCTION 

This  paper  will  describe  some  of  the  results  of  a develop- 
ment program  carried  out  at  Standard  Telecommunication 
Laboratories  and  funded  by  MOD  (UK) . 

It  is  becoming  widely  accepted  that  optical  fibre  data 
transmission  will  find  application  in  avionics  because  of  its 
electrical  isolation,  wide  bandwidth  and  immunity  to  cross- 
talk and  radio  frequency  interference.  The  principle  has 
already  been  proved  and  advantages  demonstrated  for  avionics 
applications  in  point-to-point  links,  much  of  this  preliminary 
work  having  been  carried  out  with  fibre  bundles*'^.  In  the 
longer  term,  there  also  appear  to  be  applications  for  optical 
fibre  data  bus  systems.  For  example,  telemetry,  display 
systems  or  stores  management  could  be  suitable  choices  for 
first  applications.  The  key  optical  components  - tee-pieces, 
star  couplers,  etc  - are  at  an  early  stage  of  development,  so 
a system  cannot  be  fully  optimized  in  terms  of  these  compon- 
ents. It  is  thus  too  early  to  attempt  to  optimize  a multi- 
terminal system  for  any  particular  application;  it  is  never- 
theless important  to  start  experimental  work  on  multi-terminal 
systems  at  this  stage.  This  will  ensure  that  the  possibilities 
of  the  new  technology  are  included  in  the  long-term  data 
management  plans.  Otherwise,  a framework  set  up  on  the  basis 
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of  conventional  technology,  with  fibre  systems  designed  to  fit 
in  at  a later  stage,  would  fall  to  make  full  use  of  the 
potential. 

The  other  reason  for  undertaking  immediate  experimental 
work  is  to  help  direct  the  development  of  key  optical 
components  such  as  tee-pieces  and  star  couplers.  In  addition 
to  using  fibre  systems  to  meet  conventional  requirements  more 
efficiently,  there  must  be  new  opportunities  which  would  not 
be  considered  for  electrical  systems.  Direct  optical  sensing, 
without  electrical  interfaces,  is  a possible  example. 

The  system  approach  adopted,  in  which  any  number  of 
terminals  up  to  a given  maximum  (ten  in  our  example)  with  no 
requirement  for  a master  terminal,  and  with  great  flexibility 
for  the  system  designer  to  arrange  redundancy,  self-checking 
etc,  is  likely  to  be  widely  applicable.  (It  can  even  be  used 
for  point-to-point  tests,  simply  by  connecting  any  two 
terminals) . No  clear  preferred  optical  highway  configuration 
emerges,  and  so  initial  experimental  systems  should  allow  this 
to  be  flexible. 

The  system  described  has  been  designed  to  be  compatible 
not  only  with  a 'star*  configuration  optical  harness,  which  is 
'well  behaved'  from  the  point  of  view  of  the  terminals,  but 
with  almost  any  complex  highway  configuration  which  may  have 
advcuitages  of  considerable  redundancy  and  be  adaptable  to 
constraints  on  layout,  maintenance,  etc.  Such  complex  high- 
ways may  be  prone  to  optical  echo  pulses  and  other  problems , 
as  outlined  in  Section  2. 

It  is  important  to  emphasise  that  the  terminal  design 
outlined  here  is  considerably  more  complex  than  is  envisaged 
in  a typical  system.  The  reason  is  that  this  is  an  experi- 
mental system,  not  an  optimized  communication  link  for  a 
particular  application,  and  many  of  the  facilities  can  be 
implemented  or  switched-out  at  will,  in  order  to  gain 
experience.  It  is  also  expected  that  significant  simplific- 
ations could  be  made,  although  at  the  expense  of  demanding 
improved  optical  harness  performance. 

2.  SYSTEM  OUTLINE 

2 . 1 General  Multi-Terminal  Design 

The  choice  of  multiplexing  technique  depends  on  the  capa- 
bilities and  limitations  of  the  transmission  medium,  and  on 
the  use  that  is  to  be  made  of  the  entire  system.  For  an 
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optical  fibre  several  alternatives  exist  and  several  solutions 
are  listed  below; 

i)  Time  division  multiplexing,  TDM,  where  each  transmitter 
in  turn  has  sole  use  of  the  optical  highway. 

ii)  Frequency  division  multiplexing,  FDM,  where  each  trans- 
mitter uses  an  optical  source,  amplitude  modulated  at  a 
different  frequency.  This  carrier  can  be  amplitude  or 
frequency  modulated  with  information.  The  total  received 
signal  is  filtered  electrically. 

iii)  Colour  multiplexihg  - each  transmitter  uses  a different 
wavelength  source,  and  filters  at  the  photodiodes 
separate  the  signals. 

It  was  decided  that  the  TDM  approach  was  most  suitable  for 
systems  requiring  data  interchange  between  any  pair  of  terminals 
and  so  that  system  will  now  be  discussed  in  more  detail. 

2 .2  The  TDM  System 

2.2.1  Synchronisation 

For  a TDM  system,  where  only  one  transmitt  il towed  to 

send  Information  at  any  one  time,  the  timing  at  la  ■ nts  are 
of  crucial  importance.  The  most  straightforwai  ming  arrange- 
ment is  through  the  use  of  a master  terminal,  win.  le  a single 
master  unit  has  responsibility  for  absolute  timing,  and  sends 
whatever  information  is  needed  to  the  other  terminals  to 
maintain  the  synchronisation  of  the  system.  In  the  extreme, 
the  master  terminal  can  make  all  decisions  about  timing  and 
can  send  a short  message  to  each  terminal  in  turn  to  start 
its  transmission.  This  approach  can  give  a very  flexible 
system,  where  time  can  be  allocated  by  the  master  tentiinal  in 
a way  that  varies  with  the  amount  of  information  needing 
transfer,  and  this  leads  to  very  efficient  use  of  the  data  bus. 
Unfortunately,  this  arrangement  gives  a single  vulnerable 
point  in  the  master  terminal  where  damage  or  a fault  can 
disrupt  the  whole  system,  a situation  which  can  be  improv’ed 
by  having  several  terminals  ready  to  take  over  from  the  master 
if  it  should  fail.  This  in  turn  requires  a system  of 
priorities  being  allocated,  to  specify  which  terminal  will  take 
over  first,  and  involves  many  problems  in  deciding  whether  the 
first  unit  has  failed  or  not.  To  avoid  this  eventuality,  it 
may  be  preferable  that  there  should  be  no  master  terminal,  in 
which  case  each  terminal  must  do  its  own  timing  and  some  means 
must  be  found  of  keeping  all  the  terminals  in  synchronism. 
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figure  IBI  GAUSSIA.N  NOISt 


This  approach  was  adopted  and  will  be  described  in  more  detail 
in  Section  2.3. 

One  further  consequence  of  this  'autonomy'  of  the 
terminals  is  that  the  data  tr.uismission  capacity  of  them 
must  be  predetermined,  and  cannot  easily  be  changed  to  meet 
different  network  loadings.  This  approach  is  thought  accept- 
lible  for  a fibre-optic  network  as  the  high  bandwidth  avail- 
able means  that  excess  data  capacity  can  be  made  available  at 
low  cost. 

2.2.2  Coding 

The  choice  of  coding  in  an  i->ptical  systi'm  '.in  cons  I diM'ab  ly 
effect  the  rest  of  the  design.  Ki't  eximple,  I h«*  ctinice  of  a 
PPM  code  would  enable  a low-duf  y-i-y  i- Ic  opflcal  s»niti-e  t ii  bi’ 
used,  or  a code  with  no  low  fie,pien.y  content  wmiU*  alb’w  an 
a.c.  coupled  receive!  to  be  use»).  )*»•  iiisi-  't  1 1*.'  taotif 
changes  of  signal  level  expei'ted  at  a i cimm  , it  is  tfesiiabU 
that  the  chosen  code  shinild  allow  l • t « i • - Is-  appMed. 
Another  requirement  is  that  tin*  data  ••  l<.-  ^ islly 

extracted  from  the  liata,  pieti-i  iblx  wi?  ' . exc  of  a pfiase- 

locked  loop.  This  is  necess.iiy  b**.  c ■ « ;\e.f  message 

will  be  at  a different  pha«»'  dm  i • . • l- it  h lengtfis 

involved.  A short  preamble  can  In-  : r . ■ '■  ••.•sHac«>  t 

allow  the  receiver  dei'oiiei  to  se»  t • thi  . is  t .'o 

long  then  the  system  becimum  ''im^  n 


The  most  appropri.it  i*  cinle  woiil  ».  ; i p--. asc 

(Manchester)  (see  Fixi.2.1'  .is  tins  t i i.txant  a.ies . 

There  is  a data  transition  .it  ttn-  entti  • ...ox  , lock 

interval  which  m.ikes  cliick  ext  t ai-t  U'li  e isx  . it  -tily  fiein.i 
necessary  to  time  from  one  cy.-le  t c-  t tie  nest  with  a ile  1 ay 
element  siu-li  .is  a monost.ible.  The  bl  pliase  -..hI,.  it,  also 
arranged  to  have  very  little  K'w- f i e»pien«  y i-ontent,  wh.ite\-et 
the  data  being  sent.  This  occui  s bevaust*  t tie  cinfe  ti.is  .i 
constant  average  value  fot  ones  .iiuf  n»'iiglits.  Tills  a 1 Ktws 
fast  a.g.c.  and  a.  c.-coupleil  ie>'eivers  to  be  ustul,  .is  stated 
above . 


This  code  is  most  ideally  auitexl  to  blpol.n  applications 
where  differential  signalling  is  employeil.  Unfortunately, 
this  cannot  easily  be  achieved  with  a single  optical  fibre 
and  so  a unipolar  version  must  bo  used,  introilucing  the  liis- 
advantage  of  needing  a threshold  shift  if  the  signal  strength 
changes,  as  illustrated  in  Fig.  2.1. 


2 . 3 Proposed  System  Outline 
2.3.1  General  Description 

The  system  that  has  been  built  at  Standard  Telecommun- 
ication Laboratories  has  been  described  elsewhere’  and  so 
only  an  outline  is  included  here.  A block  diagram  of  one 
terminal  is  shown  in  Fig.  2.3. 


A time  division  multiplex  (TDM)  approach  has  been  chosen 
where  each  transmitter  in  turn  has  complete  use  of  the 
optical  highway,  for  a burst  period.  See  Fig.  2.2.  A fixed 
length  message  is  transmitted  in  that  period,  complete  with 
an  address  code  to  specify  the  terminal  that  is  to  receive 
it.  The  transmitters  send  in  strict  rotation,  and  if  a 
terminal  is  inoperative,  or  if  no  information  is  available 
for  sending,  then  that  period  is  either  left  empty  or  a dummy 
message  is  sent.  Each  terminal  contains  its  own  clock 
oscillator  and  divider  chain  which  provides  all  the  timing 
information  within  the  terminal.  These  clocks  must  be  kept 
approximately  in  step  so  that  the  transmission  periods  do  not 
overlap.  This  has  been  achieved  by  making  each  transmitted 
message  contain  the  address  of  the  sending  terminal,  which 
is  received  by  all  other  units  and  used  to  correct  small 
timing  errors  that  have  developed.  Special  attention  has 
been  paid  to  the  problems  of  synchronisation  from  switch-on 
and  to  the  effects  of  a single  faulty  terminal. 

2.3.2  Basic  Design  Parameters 


The  following  parameters  have  been  chosen  for  these 
functional  models.  They  were  chosen  as  examples  only,  and 
it  is  expected  that  they  would  be  altered  in  any  design  to 
meet  a specific  application. 


Number  of  terminals 

Bit  rate  of  transmission 

Transmission  data  rate 
per  terminal 

Optical  transmitter 

Optical  receiver 

Optical  harness  layout 

The  system  was  designed  to  have  no 


up  to  10 
1.5  Mbit/s 

100  kbit/s 

Bell  Northern  LED 

PIN  diode  (Hewlett  Packard) 

to  be  flexible,  with 
losses  up  to  30  dP 

master  terminal. 


The  message  format  has  been  chosen  to  give  a high  degree 
of  protection  to  the  service  data.  The  basic  arrangement  Is 
shown  In  Fig.  2.2.  In  the  17  bits  allocated  to  each  address, 
the  terminal  number  Is  sent  twice,  and  this  is  followed  by 
em  Invalid  bit  sequence  to  differentiate  the  address  from 
the -data.  This  degree  of  protection  Is  necessary  as  the 
terminal  receivers  are  active,  looking  for  address  codes,  at 
all  times,  and  in  between  messages  are  trying  to  decode 
random  noise. 

The  data  is  sent  as  a block  of  128  bits  with  8 added 
parity  bits. 

2.3.3  Fault  Protection 

The  multi-terminal  system  as  described  Is  very  flexible, 
and  various  self-checking  features  could  be  built  into  the 
terminals.  The  timing  section  ensures  that  a terminal  with  a 
faulty  clock  divider  will  shut  down  Its  own  transmitter  as  it 
will  continually  find  large  errors  between  its  own  clock  and 
the  other  terminals.  This  is  probably  the  most  serious  type 
of  fault  that  could  occur  as  it  might  result  in  transmission 
at  incorrect  intervals,  so  corrupting  other  terminals'  data. 

Another  form  of  protection  is  the  maximum  transmission  time 
limit.  The  period  for  which  the  transmitter  is  active  should 
never  exceed  a certain  limit.  This  is  timed  independently, 
and  if  the  limit  is  exceeded  the  transmitter  is  shut  down. 

Parity  checking  is  incorporated  into  the  system  by 
inserting  one  parity  bit  after  every  16  bits  of  data.  This 
is  checked  by  the  receiver  so  that  a message  with  a parity 
fault  can  be  rejected. 

Message  confirmation  could  be  incorporated  to  provide 
protection  against  random  errors.  This  has  not  been  done, 
however,  in  the  functional  models.  Confirmation  could  take 
the  form  of  an  added  service  data  section  in  which  a terminal 
can  acknowledge  receipt  of  messages  in  the  last  frame.  If 
receipt  was  not  acknowledged  the  message  could  be  retransmitted 
by  the  sending  terminal.  A suitable  code  for  this  is  suggested 
as  a ten-bit  word  (for  ten  terminals  in  the  system) . All  bits 
would  normally  be  zero  with  one  bit  in  the  sequence  to  repres- 
ent each  terminal.  This  bit  would  be  sent  to  indicate  tliat  a 
parity-correct  message  has  been  received  from  that  terminal  in 
the  last  frame.  Alternatively,  this  type  of  message  checking 
can  be  built  into  the  external  equipment  as  it  may  only  be 
required  over  limited  paths. 
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A more  general  checking  system  could  consist  of  a special- 
purpose  terminal  which  monitors  all  information  on  the  bus. 

By  checking  for  parity  correct  messages,  and  correct  trans- 
mitter sequence,  etc,  it  should  be  possible  for  the  monitor 
to  isolate  faulty  terminals.  The  monitor  could  then  be  given 
the  power  to  shut  down  faulty  units.  If  this  was  .mplemented 
care  would  have  to  be  taken  that  the  overall  reliability  was 
not  reduced. 

3 . COMPUTE  R S IMULAT ION 

3 . 1 Objectives 


The  computer  simulation  was  carried  out  at  an  early  staqe 
In  the  project  to  investigate  the  synchronisation  behaviour 
of  the  proposed  system.  It  was  considered  necessary  to  verify 
the  expected  behaviour  in  this  way  as  the  synchronisation 
behaviour  of  a multi-terminal  system  with  no  master  is  ve^' 
complicated.  There  are  many  interdependent  feedback  loops 
involved  and  it  was  useful  to  check  that  no  undesirable  stable 
situations  have  been  overlooked.  This  is  particularly 
important  for  a multi-terminal  system  as  final  testing  can 
only  be  carried  out  with  confidence  when  several  (at  least 
three)  complete  terminals  have  been  built. 

To  serve  the  purpose  the  computer  model  used  was  the 
simplest  possible  representation  of  the  system  and  not  a 
detailed  hardware  simulation. 

3.2  Results  of  Computer  Simulation 

The  computer  simulation  is  arranged  to  run  from  specified 
start  conditions  until  the  synchronisation  conditions  are 
satisfied,  when  it  stops  and  prints  the  number  of  frames  that 
have  elapsed.  Intermediate  results  can  also  be  printed,  and 
have  been  used  to  verify  the  operation  of  the  program.  All 
the  system  variables  can  be  preset  (timing  counter,  error 
counter,  enable-disable  flag,  clock  frequency  differences) 
giving  an  enormous  number  of  combinations,  and  so  only  a few 
can  be  tried. 

To  investigate  a wide  range  of  possible  start-up  conditions 
the  program  has  been  arranged  to  take  random  values  for  its 
timing  counter  as  initial  values,  and  the  result  of  many  runs 
are  plotted  as  a histogram.  The  start  conditions  of  the  error 
counters  have  been  found  to  have  very  little  effect  on  synch- 
ronisation times,  and  so  their  start  conditions  are  taken  as 
zero. 
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Fig.  3.1  shows  a typical  plot  produced  in  this  program. 

It  shows  a mean  synchronisation  time  of  2.6  frames  with  a 
standard  deviation  of  0.57. 

The  very  short  synchronisation  times  indicated  agree 
approximately  with  the  experimental  results,  except  that 
the  experimental  results  show  a longer  tail,  with  some  very 
long  synchronisation  times.  This  was  thought  to  be  due  to 
the  optical  harness  used,  which  was  a 'star'  configuration. 

The  program  assumes  that  a ring  is  used,  which  would  give  a 
single  usable  signal  at  every  receiver,  however  many  trans- 
mitters are  active.  This  is  because  of  the  sequential  losses 
around  the  ring.  With  a star  configuration  all  optical  losses 
are  the  same  and  two  transmitters  will  give  approximately  equal 
signals  at  any  receiver.  This  means  that  when  transmissions 
overlap  the  result  is  that  no  receiver  gets  a usable  signal. 

The  computer  program  was  altered  to  try  this  arrangement, 
an  occasional  long  synchronisation  times  resulted. 

4.  EXPERIMENTAL  RESULTS 

4. 1  General  Operation 

The  general  operation  of  the  four  terminals  has  been 
checked  with  the  aid  of  a four-channel  oscilloscope.  Fig. 

4.1  shows  the  four  transmission-time  waveforms  with  the 
terminals  set  as  O,  2,  4 and  6 and  Fig.  4.2  shows  the  corres- 
ponding signal  received  by  one  of  the  optical  receivers. 

Figs.  4.3  and  4.4  are  the  same  waveforms,  but  this  time  taken 
with  the  terminals  set  as  numbers  O,  1,  2 and  3. 

The  action  of  the  timing  correction  circuits  has  been 
closely  checked  for  a two-terminal  set.  With  only  two 
terminals  connected,  and  their  clocks  adjusted  to  be  very 
similar,  it  is  possible  to  observe  the  small  timing  corrections 
taking  place. 

Another  check  that  has  been  carried  out  on  all  terminals 
is  to  connect  them  as  relays  by  linking  digital  output  to 
input.  If  the  terminal  is  then  used  to  relay  a message, 
originated  by^ a word  generator  at  another  terminal,  the 
operation  of  the  input  and  output  circuitry  is  checked. 

Fig.  4.5  shows  the  arrangement  used. 

4.2  Error  Rate  Measurements 


An  error  measuring  counter  has  been  built  for  use  with 
this  equipment.  It  is  based  on  a microprocessor,  which  controls 
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a pseudo- random  word  generator  and  checking  circuit.  The 
microprocessor  totalises  the  errors  counted  on  each  message, 
and  also  counts  the  number  of  complete  messages  that  are 
'lost',  corresponding  to  an  error  occurring  in  the  message 
address.  Using  this  equipment,  it  has  been  verified  that 
under  normal  operating  conditions  error  rates  are  extremely 
low.  Under  conditions  of  reduced  signal,  errors  do  occur, 
cind  Fig.  4.6  shows  a plot  of  error  rate  against  received 
power  for  one  receiving  terminal. 

The  flattening-off  of  the  bit  error  rate  at  low  received 
powers  is  thought  to  be  due  to  the  fact  that  lost  messages 
are  not  included  in  this  count,  emd  so  for  very  low  received 
powers  the  bit  error  rate  would  fall  to  zero,  as  the  message 
error  rate  rises  to  unity. 

The  curve  for  error  rate  can  be  extrapolated  giving  an 
error  rate  of  1 in  10®  for  a received  power  of  -42.5  dBm. 

These  error  measurements  have  also  been  used  to  show  the 
independence  of  the  data  paths.  With  one  transmitter's 
power  reduced  to  introduce  errors,  the  effects  of  having 
full  strength  transmitters  operating  immediately  before  and 
after  the  test  unit  have  been  investigated.  Fig.  4.7  shows 
the  signal  at  an  optical  receiver,  both  with  and  without  the 
full  strength  transmitters.  The  reduced  strength  signal 
shows  as  a non-limited  output  from  the  optical  receiver.  K’o 
dependence  between  transmitters  has  been  found,  as  the 
monitored  error  rates  were  not  found  to  change  when  the  other 
units  were  switched  on. 

4 . 4 Optical  Power  Budget 

The  transmitted  power  from  each  of  the  four  LEbs  used  was 
measured  to  be  greater  than  200  yW  mean  during  the  transmission 
burst.  This  is  the  optical  power  launched  into  a 150  vim  core 
fibre,  with  NA  •vO.2.  Taking  the  minimum  received  power 
necessary  to  be  -42.5  dBm  (from  Section  4.2  above)  this  means 
that  the  maximum  allowable  optical  loss  between  any  trans- 
mitter and  receiver  is  35.5  dB. 

Allowing  for  ageing  and  temperature  effects  in  both  trans- 
mitter and  receiver,  and  allowing  for  some  system  margin, 
optical  losses  of  up  to  30  dB  would  be  acceptable. 

The  dynamic  range  of  the  receiver  has  been  shown  to 
greater  than  40  dB  and  so  there  are  no  constraints  on  the 
optical  harness  loss  differences,  so  long  as  the  maximum  loss 
is  not  exceeded  over  any  path. 
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5. 


DEMONSTRATION  OPTICAL  HARNESS 


A harness  has  been  constructed  which  can  be  used  to  test 
the  system's  immunity  to  echo  pulses  arising  from  multiple 
path  and  reflection  effects. 

The  harness  consists  of  single  fibre  4--way  equal-division 
transmission  stars  and  a set  of  fibres  of  various  lengths  for 
connection.  These  components  allow  the  interconnection  of  the 
terminals  with  various  degrees  of  redundancy.  See  Fig.  5.1. 

Typical  insertion  losses  for  a 4-way  transmission  star 
are  <10  dB  between  any  pair  of  ports.  Optical  losses  between 
the  mixers  are  only  due  to  connectors  as  very  low  loss  fibres 
were  used,  and  their  attenuation  can  be  neglected  for  the 
length  likely  to  be  used  within  an  aircraft. 

6.  CONCLUSIONS 

The  four-terminal  system  with  no  central  controller  has 
been  shown  to  work  with  a range  of  different  optical  harness 
configurations  and  losses. 

The  design  approach  described  would  seem  to  offer  a viable 
architecture  for  a multi-terminal  data  system,  especially  for 
applications  where  a central  bus  controller  is  undesirable. 
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Fig.2.3  Terminal  block  diagram 


Fig.  4.1  Transmission  lime  intervals  from 
terminals  0,2,4  and  6 


Fig.  4.2  Received  signal  at  one  optical 

receiver  for  conditions  as  in  Fig  4.1 


i 


Fig.  4.3  Transmission  time  intervals  for  terminals 
0,1,2  and  3 


Fig.  4.4  Received  signal  from  one  optical  receiver 
for  conditions  as  in  Fig.  4.3 
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(b)  Tesl  condition  2-  with  extra  transmitters 


Fig.  4.7  Optical  receiver  outputs  during  error  tests 
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THE  IMPACT  OF  FIBER  OPTIC  MULTIPLEXING 
ON  DISTRIBUTED  AVIONICS  ARCHITECTURE  DESIGN 

James  M.  Bain 

Air  Force  Avionics  Laboratory 
Dayton,  Ohio 


ABSTRACT 

The  development  of  low  cost  microcomputers  has 
initiated  a trend  towards  distributed  architectures  in 
avionics.  Such  architectures  require  high  levels  of 
interprocessor  communications  which  may  exceed  the  capa- 
city of  current  1 MHz  avionic  multiplex  buses.  The  wide 
bandwidth  (10  MHz)  of  a fiber  optics  multiplex  bus  can 
be  used  to  satisfy  the  increased  bus  traffic  requirements 
of  distributed  processor  systems,  however,  this  is  not 
the  only  benefit  of  using  a wideband  bus  in  such  systems. 
Due  to  the  unique  characteristics  of  distributed  archi- 
tectures, it  is  possible  for  the  designer  to  use  fiber 
optic's  wide  bandwidth  to  enhance  system  capabilities. 

The  Air  Force  has  developed  a conceptual  avionics  archi- 
tecture which  demonstrates  the  advantages  of  using  fiber 
optics  multiplexing  in  a distributed  processing  environ- 
ment. 

TRENDS  IN  AVIONICS  PROCESSING  ARCHITECTURES 

Digital  avionic  architectures  of  the  mid  1960 's 
consisted  of  one  or  two  central  minicomputers  interfaced 
to  a large  analog- to-digital  (A/D)  converter,  which  in 
turn  was  interconnected  to  various  sensors,  actuators, 
controls,  and  displays  through  a network  of  dedicated 
wire  paths.  Examples  of  this  centralized  processing 
approach  include  the  F-lllD  Mark  II  system  and  the  A-7D 
avionics . 

In  the  F-15,  a federated  processing  approach  was  taken 
in  which  separate  minicomputers  of  different  types  are 
used  to  perform  navigation,  radar  and  electronic  counter- 
measures processing.^  Another  innovation  of  the  F-15 
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was  to  distribute  A/D  conversions  throughout  the  air- 
craft in  the  form  of  Remote  Terminals  (RTs)  intercon- 
nected by  a serial  digital  multiplex  data  bus. 

The  recent  appearance  of  low  cost  microprocessors 
has  made  it  practical  to  distribute  processing  to  the 
avionics  subsystems  themselves.  This  reduces  the  amount 
of  data  which  must  be  bused  to  the  minicomputer  for 
processing  and  consequently  reduces  both  data  latency 
and  bus  loading.  This  "partially  distributed"  approach 
was  used  on  the  F-16  program. 

For  future  avionics  systems,  it  will  be  possible  to 
go  a step  further  and  eliminate  the  minicomputer  entirely, 
replacing  it  with  a network  of  standardized,  homogeneous 
single  chip  microcomputers  embedded  in  avionics  subsystems 
and  interconnected  by  a data  bus.  Such  designs  are 
commonly  called  "distributed  processing  systems"  and 
have  the  potential  to  provide  many  advantages,  most 
notably/  low  cost,  modular  hardware,  incremental  growth, 
self  organizing  architectures , and  simplified  software. 

In  summary,  a trend  towards  distributed  architectures 
in  avionics  is  apparent.  Architectures  have  evolved  from 
centralized  to  federated  to  the  currently  used  partially 
distributed  approach;  the  microcomputer  revolution  and 
the  advantages  of  distributed  networks  assure  that  many 
future  systems  will  be  fully  distributed. 

IMPACT  OF  DISTRIBUTED  PROCESSING  ON  MULTIPLEX  SYSTEM 
REQUIREMENTS 

The  distributed  processing  approach  has  a number  of 
implications  on  multiplex  system  design.  To  explore 
these,  the  Air  Force  conducted  the  Distributed  Processor/ 
Memory  Study  to  design  a distributed  architecture  and 
associated  multiplex  system  for  avionics . 2 / H 

A significant  finding  of  the  DP/M  study  was  that  a 
fully  distributed  processing  approach  generates  more 
data  bus  traffic  than  a centralized  or  federated  approach. 
This  is  the  net  result  of  two  effects  of  distributed  pro- 
cessing, one  which  tends  to  reduce  bus  traffic  and  another 
which  tends  to  increase  traffic.  The  effects  are  described 
below. 

As  mentioned  before,  distributed  microprocessors 
can  be  used  to  reduce  bus  traffic  in  a centralized  or 
federated  system.  If  a data  source  and  sink  are  located 
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at  the  same  terminal,  and  if  the  amount  of  processing 
required  is  small,  a local  microprocessor  at  the  ter- 
minal or  subsystem  can  provide  the  necessary  processing. 
Consequently,  it  will  no  longer  be  necessary  to  bus  the 
data  to  a minicomputer  for  processing  and  bus  processed 
data  back  to  the  terminal.  This  saves  two  bus  transac- 
tions each  time  new  data  is  processed.  Note  that  this 
technique  of  using  microprocessors  to  reduce  bus  traffic 
can  only  be  used  when  processing  results  are  not  needed 
by  other  terminals  or  computers.  Since  avionics  pro- 
cessing is  characterized  by  large  amounts  of  shared 
data,  a point  will  be  reached  at  which  adding  more  micro- 
processors will  no  longer  reduce  bus  traffic. 


If,  at  this  point,  the  minicomputer  is  eliminated 
and  replaced  by  additional  distributed  microprocessors, 
the  result  will  be  a fully  distributed  processing  system. 
Note  that  this  transition  involves  the  separating  into 
multiple  processors  of  software  tasks  which  formerly 
resided  in  one  processor  and  communicated  via  a shared 
memory.  Once  partitioned  into  separate  processors,  these 
software  tasks  must  communicate  over  the  bus,  consequently, 
data  bus  traffic  will  increase.  The  degree  of  increase 
depends  on  the  number  of  microcomputers  used,  their  size, 
and  the  interprocess  communication  requirements  of  sys- 
tem software.  Quantitative  analyses  indicate  that  if 
avionic  system  processing  is  partitioned  into  numerous 
small  processors,  the  increased  bus  traffic  requirements 
will  be  beyond  the  capabilities  of  current  1 Meaabit 
per  second  (Mbps)  avionic  multiplex  systems. Using 
MIL-.^^TD-ISSIA  protocol,  the  author  has  calculated  that 
a 2-4  Mbps  bus  would  be  required  for  such  systems. 


MULTIPLEX  SYSTEM  DESIQN  FOR  DISTRIBUTED  PROOESSINO  NETWORKS 


Having  established  that  many  future  avionics  process inq 
schemes  will  be  distributed  and  chat  bus  traffic  in  some 
such  systems  will  exceed  the  capabilities  of  current 
multiplex  systems;  the  need  to  desian  high  performance 
multiplex  systems  for  distributed  processor  networks  is 
apparent.  The  DP/M  study  developed  such  a system  usinq 
standard  1 MHz  capacity  twisted  shielded  wire  pair  (TSP) 
multiplex  channels.  The  approach  was  to  increase  avail- 
able system  bandwidth  by  using  a multiple  hierarchical 
bus  topology,  and  to  minimize  bus  traffic  requirements 
by  optimal  partitioning  of  software.  Since  the  bus 
design  uses  standard  multiplex  cable,  it  could  be 
implemented  in  near-term  systems. 

* A iMHz  channel  can  carry  1Mbps  of  Manchester  encoded 
digital  data. 
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For  future  systems,  an  alternate  approach  to  satis- 
fying the  increased  bus  traffic  requirements  of  distri- 
buted processor  networks  will  be  to  use  a wideband  fiber 
optics  data  bus.  Recently,  the  Air  Force  has  developed 
a laboratory  demonstrator  of  a nine-terminal  data  bus 
which  can  execute  MIL-STD-1553  bus  protocol  at  a rate 
of  10  Megabits  per  second,^  a tenfold  increase  in  data 
throughput  over  current  wire  systems. 

Aside  from  wider  bandwidth,  fiber  optics  cables  differ 
from  wire  in  that  they  are  dielectric,  unipolar,  and  carry 
very  low  power  levels.  These  issues  were  addressed  during 
the  design  of  the  fiber  optics  bus  and  MTL-STD-1553 

compatibility  was  achieved. 

IMPACT  OF  FIBER  OPTICS  MULTIPLEXING  ON  DISTRIBUTED  AVIONIC 
ARCHITECTURE  DESIGN 

As  described  previously,  the  wide  bandwidth  of  a fiber 
optics  bus  can  be  used  to  satisfy  the  increased  bus  traf- 
fic requirements  of  a distributed  processor  system. 
However,  this  is  not  the  only  benefit  of  using  a fiber 
optics  bus  in  a distributed  system.  Because  of  the 
unique  characteristics  of  distributed  architectures, 
it  is  possible  for  the  designer  to  use  fiber  optic's 
additional  bandwidth  to  increase  system  capabilities 
and/or  simplify  system  integration.  The  following  are 
five  major  areas  in  which  fiber  optics  multiplexing  im- 
pacts tradeoffs  in  the  design  of  distributed  avionics 
architectures . 

First,  a wideband  bus  allows  increased  interprocessor 
communications  (IPC) . Consequently,  processing  can  be 
partitioned  into  numerous,  single  chip  microcomputers 
without  overloading  the  bus.  Furthermore,  software 
need  not  be  partitioned  to  minimize  bus  loading,  but  can 
be  partitioned  to  optimize  other  factors.  In  addition, 
increased  IPC  capacity  makes  possible  the  use  of  advanced 
distributed  processing  concepts  such  as  dynamic  task 
scheduling^,  resource  sharing,  and  self  organizing  archi- 
tectures. 

Secondly,  a wideband  bus  allows  the  use  of  message 
formats  and  protocols  which  are  highly  fault  tolerant. 

For  example,  each  message  can  contain  explicit  source, 
destination,  sync,  retry,  and  status  codes  in  addition 
to  data.  To  assure  maximum  integrity,  each  word  can 
contain  error  detection/correction  codes  and  each  mes- 
sage can  have  some  sort  of  error  check  at  the  end. 
Protocols  can  be  used  in  which  each  bus  transmission 
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is  explicitly  acknowledqed  by  the  receiver  with  a 
negative  or  positive  response.  Broadcasts  can  be  re- 
placed by  a multitude  of  single  destination  messages 
with  acknowledgements  from  each  receiver. 

Thirdly,  a wideband  data  bus  allows  additional  data 
sources  to  be  placed  on  the  multiplex  system  both  during 
the  original  design,  and  in  subsequent  retrofits.  A 
corollary  of  this  is  that  higher  frequency  data  sources 
can  be  placed  on  the  bus.  MIL-STD-1553A  recommends  ex- 
clusion of  data  sources  above  3KHz  bandwidth  and  calls 
those  between  400  Hz-3KHz  "areas  of  questionable  appli- 
cation" for  a TSP  data  bus.^  On  a 10  Mbps  fiber  optics 
bus,  these  limits  can  be  increased  significantly. 

A fourth  implication  of  a wideband  system  is  that 
bandwidth  can  be  used  to  simplify  bus  traffic  management 
by  reducing  requirements  for  bus  "efficiency"  and  apriori 
bus  traffic  scheduling.  Studies  in  software  development 
have  shown  that  if  a computer  program  must  be  written 
to  operate  in  a constrained  address  space,  the  cost  of 
programming  is  increased  significantly.^  An  analogous 
situation  e.xists  when  digital  data  must  be  transferred 
through  a channel  of  constrained  bandwidth.  Various 
measures  are  employed  to  increase  data  bus  ’bfficiency" 
and  thereby  squeeze  additional  data  onto  the  bus.  With 
a tenfold  increase  in  available  bandwidth,  "efficiency" 
is  no  longer  important.  In  fact,  using  such  advanced 
concepts  as  bus  contention  and  self-organiuing  archi- 
tectures may  allow  the  elimination  of  apriori  bus  traf- 
fic definitions  altogether,  greatly  simplifying  system 
integration  and  retrofit. ^ 

The  fifth,  and  final  implication  of  a wideband 
system  to  be  discussed  here  is  that  of  transaction  timing. 
Data  latency,  response  time  and  system  reconfiguration 
time  can  potentially  be  reduced  using  a wideband  bus 
and  contention  access  algorithms. 


•Examination  of  the  tradeoffs  discussed  above  reveals 
that  in  certain  cases  the  combination  of  a fiber  optics 
data  bus  and  distributed  microprocessors  in  an  avionic 
environment  tends  to  be  synergistic:  fiber  optic's  band- 
width can  be  used  to  obtain  significant  architectui al 
advantages,  but  intelligent  BIUs*are  required  to  use  this 
bandwidth;  fully  distributed  processing  can  provide  ad- 
vantages, but  requires  high  communication  bandwidth. 

* Bus  Interface  Units  ( also  called  "terminals"  ) 
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For  example,  an  optical  bus  provides  bandwidth  required 
for  such  schemes  as  dynamic  task  scheduling  and  error 
correcting  codes,  but  distributed  processors  are  required 
to  implement  such  schemes;  conversely,  distributed  archi- 
tectures provide  the  potential  to  partition  software 
among  low  cost  single-chip  processors,  but  this  generates 
additional  bus  traffic.  It  could  be  said  that  a distri- 
buted network  is  needed  to  make  optimal  use  of  an  optical 
bus,  and  vice  versa.  The  combination  of  distributed  pro- 
cessing and  fiber  optics  has  the  potential  to  provide 
highly  advanced  architectures. 

A CONCEPTUAL  ARCHITECTURE  FOR  AVIONICS 

The  pr'^vious  section  listed  some  of  the  ways  in  which 
the  capabili  ies  of  fiber  optics  multiplexing  could  im- 
pact the  design  of  distributed  architectures.  The  designer 
of  a future  avionics  system  must  select  from  this  list 
those  techniques  which  are  applicable  to  his  system 
requirements.  He  must  keep  in  mind  that  some  of  the 
techniques  described  are  mutually  exclusive  and  others 
are  still  in  the  research  stage.  Nevertheless,  the 
emerging  technologies  of  fiber  optics  and  distributed 
processing  give  the  designer  a vast  array  of  architectural 
alternatives. 

As  a first  step  in  realizing  the  potential  advantages 
of  fiber  optics  and  distributed  processing,  the  Air  Force 
Avionics  Lab  has  conducted  a study  to  define  a distri- 
buted avionics  architecture  concept  with  wideband  fiber 
optics  multiplexing. 3 The  approach  was  to  select  a 
specific  avionics  suite  and  mission,  and  to  design  a 
system  to  satisfy  those  requirements  by  selecting  those 
techniques  described  in  the  previous  section  which  were 
felt  to  be  most  applicable. 

Three  candidate  avionic  distributed  processing  archi- 
tectures were  developed  during  the  study  and  are  described 
in  detail  in  reference  3.  One  was  optimized  for  per- 
formance, another  for  fault  tolerance,  and  the  third  for 
low  development  risk.  A fault  tolerant  architecture 
called  the  Passive  Bus  System  will  be  briefly  described 
here.  The  description  will  emphasize  topology/redundancy, 
bus  control,  protocol,  message  formats,  and  subsystem 
software  interface.  Detailed  issues  of  hardware  imple- 
mentation were  beyond  the  scope  of  the  study. 

The  system  topology  features  a quad  redundant  bus 
architecture  and  a passive  fiber  optics  bus.  Radial 
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arm  couplers  would  be  located  at  widely  separated  loca- 
tions on  the  aircraft  to  enhance  survivability.  Fully 
redundant  BIUs  were  judged  too  expensive;  non  redundant 
BIUs  were  not  sufficiently  reliable. 

Bus  control  in  this  system  is  performed  in  a con- 
tention mode  using  an  "Ethernet" 10  form  of  contention. 
Consequently,  there  is  no  central  bus  controller  and 
no  computer  memory  is  reeded  to  store  static  bus  sche- 
dules. The  scheme  works  as  follows:  A Bus  Interface 
Unit,  when  desiring  to  send  a message, waits  until  the 
bus  is  quiet  and  begins  to  transmit,  and  "listens"  for 
a collision.  If  one  occurs,  the  BIU  transmits  invalid 
modulation  briefly  to  make  sure  that  all  BIUs  detect  the 
collision.  After  the  collision,  each  BIU  refrains  from 
using  the  bus  (times-out)  for  a random  time  period,  with 
standard  deviations  adjusted  according  to  priority.  The 
BIU  with  the  shortest  time-out  gains  control  of  the  bus. 
When  that  BIU  vacates  the  bus  it  sends  a "bus  available" 
signal . 

The  collision  bus  allocation  scheme  was  chosen  because 
it  exhibits  a high  tolerance  to  errors  and  BIU  failures 
(no  reconfiguration  is  required) . Resynchronization 
occurs  with  each  transaction.  In  addition,  the  scheme 
is  fast,  dynamic,  provides  reduced  response  time,  and  has 
optimal  priority  response.  It  satisfies  the  requirement 
of  real-time  systems  to  assign  opportunities  to  use  the 
bus  in  any  sequence  and  with  any  percentage  of  bandwidth. 
The  collision  scheme  is  well-matched  to  bus  systems  with 
minimum  propagation  delay  and  wide  bandwidth  such  as  the 
fiber  optics  Passive  Bus  System. 

The  protocol  selected  is  designed  for  high  integrity. 
All  messages  in  the  passive  bus  system  are  transmitted 
on  a one-to-one  basis  from  source  to  destination  with 
no  third  party  involved.  This  single-destination  method 
of  transmission  was  chosen  over  broadcast  mode  because 
it  provides  improved  fault  tolerance  at  the  expense  of 
bus  bandwidth.  This  is  an  acceptable  tradeoff  because 
with  fiber  optics  there  is  little  motivation  to  minimize 
the  use  of  bus  bandwidth.  Single-destination  messages 
allow  for  definitive  positive  and  negative  acknowledge- 
ments, thus  raising  system  integrity.  With  four  10  Mbps 
buses,  most  performance  requirements  can  be  met  with 
virtual  broadcast  at  the  subsystem  level  which  is  trans- 
lated into  a multiplicity  of  single-destination  messages 
at  the  BIU  level,  thus  maintaining  high  integrity. 
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FIBRE  OPTIC  REGENERATIVE  MULTI -ACCESS  NETWORK 

Robin  D.  Beasley 

Flight  Automation  Research  Laboratory 
Marconi  Avionics  Limited 

I Rochester  Kent  UK 


1 INTRODUCTION 

Marconi  Avionics  Limited  recognised  the  potential  benefits  to 
avionic  systems  of  fibre  optic  data  transmission  more  than  a decade 
ago.  After  two  initial  research  programmes,  the  company  implem- 
ented the  use  of  fibre  optics  on  the  YC14  flipht  control  system  and  also 
entered  into  a Ministry  of  Defence  (PE)  funded  fibre  optic  component 
development  programme  known  as  MINILINKS, 

The  MINILINKS  components  were  then  used  in  installation  trials 
at  British  Aerospace  Warton,  which  were  carried  out  tinder 
representative  production  conditions.  These  programmes  have 
resulted  in  A-B  links  based  on  fibre  bundles  being  established  as  a 
practical  technology. 

The  advent  and  apparent  rapid  acceptance  of  Mil-Std-1553 
combined  with  other  avionic  and  aviation  developments,  has  led  to  the 
likely  requirement  for  a fibre  optic  multi -access  network  which  is 

compatible  with  the  Mil  Std.  The  Flight  Automation  Research  M 

Laboratory  (FARL)  of  Marconi  Avionics  Ltd  undertook  the  develop- 
ment  of  such  a network  twelve  months  ago,  and  the  result  of  this  work  i j 

is  known  as  FOREMAN  (Fibre  Optic  REgenerative  Multi  Access  jj 
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Network).  The  main  objective  of  FORfeMAN  is  to  aUow  the  rapid 
implementation  of  a Mil-Std-1553  fibre  optic  network,  but  with 
minimal  effect  on  existing  avionic  unit  construction  and  airframe 
installation. 

2 EXISTING  FIBRE  OPTIC  TECHNOLOGY 

The  problems  of  using  fibre  optic  bundle  technology  in  the  avionic 
environment  were  overcome  by  Marconi  Avionics  Limited  during  the 
design  of  the  YC14  Flight  Control  System  and  the  MINILINKS  contract. 
The  MINILINKS  components  were  designed  for  general  system  use  and 
thus  the  technology  is  very  applicable  to  fibre  optic  multi  access 
networks.  A brief  review  of  the  MINILINKS  contract  and  the  install- 
ation  trials  is  included  in  this  section  as  it  relates  directly  to  the 
design  philosophy  of  FOREMAN. 

2.1  MINILINK  COMPONENT  DEVELOPMENT 

At  the  beginning  of  the  MINILINKS  contract,  a survey  was  carried 
out  to  identify  the  most  applicable  system  specifications  for  an  avionic 
fibre  optic  data  transmission  link.  Fig  1 shows  a pictorial  represent- 
ation of  the  results  of  the  survey.  The  survey  identified  four  main 
areas  of  development;  these  were,  military  standard  terminals, 
avionic  connectors,  a shop  floor  termination  technique  and  an  avionic 
fibre  bundle  cable. 

Fibre  optic  transmitter  and  receiver  terminals  were  developed  in 
three  stages,  and  Fig  2 shows  the  final  hybrid  module.  This  module 
is  a military  standard  hybrid  capable  of  operating  over  a temperature 
range  of  +125  C to  -55  C.  An  important  feature  of  this  hybrid 
module  is  that  it  is  capable  of  being  mo\inted  on  a printed  circuit 
board  in  a similar  manner  to  conventional  electronic  components. 

The  terminals  are  a specifiable  interface;  the  transmitter  module 
accepts  a TTL  signal  and  emits  a specified  optical  output,  and  the 
receiver  module  accepts  a minimum  optical  power  and  reproduces  the 
original  TTL  signal  applied  to  the  transmitter  module. 

It  was  decided  to  use  existing  avionic  electrical  connector  shells 
to  avoid  the  delay  involved  with  approval  or  re-approval  for  an  avionic 
fibre  optic  connector.  During  the  MINILINKS  contract  a fibre  optic 
rack  mounted  DPX  connector  and  hand  mated  TYPE  602  connector 
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An  important  development  during  the  MINILINKS  contract  was  the 
formulation,  by  FARL,  of  a 'shop  floor'  terminiition  technique  known 
as  the  'Hot  Crimp'.  The  'Hot  Crimp'  process  is  based  on  the  fibre 
optic  bundle,  contained  by  a glass  bead,  being  pushed  into  a tapered 
hole  in  a hot  jig.  This  results  in  the  end  face  of  the  bundle  forming  a 
hexagonal  close  pack.  The  basic  elements  for  this  process  have  been 
designed  to  form  a sire  12  ferrule  on  completion  of  the  termination. 
The  'Hot  Crimp'  has  a number  of  advantages  over  conventional  epoxy 
termination.  The  formation  of  a hexagonal  close  pack  reduces  the 
connector  attenuation  by  30%,  it  also  forms  an  all-glass  face  which  is 
easier  to  polish.  The  quality  of  the  termination  is  controlled  by  the 
quality  of  the  piece  parts  and  thus  requires  no  skill  on  the  part  of  the 
operator. 

The  fibre  bundle  selected  was  made  up  of  61  fibres  forming  a 
bundle  diameter  of  800  uni  and  has  an  attenuation  of  250-S00  dH/km. 
The  sheathing  consists  of  two  non-flammable  plastics.  A dual  sheath 
was  adopted  with  a soft  inner  sheath  and  a hard  outer  sheath.  This 
construction  was  found  to  provide  the  fibre  bundle  witli  adequaUe 
protection,  whilst  allowing  the  standard  'hex  crimp'  tools  used  on 
conventioivil  electrical  cable  to  be  used  to  mechanically  terminate  the 
fibre  optic  ferrule  to  the  cable. 

All  the  forementioned  components  have  been  envirotunentally 
tested  at  the  Royal  Signals  and  Radar  Establishment  Malvern,  to  the 
specification  shown  in  Fig  1. 

2.2  FIBRE  OPTIC  INSTALLATION  TRIALS 

A fibre  optic  installation  trial,  funded  by  the  Ministry  of  Defence 
(PE)  was  carried  out  by  British  Aeros^iace  Warton  and  Marconi 
Avionics  after  tlie  completion  of  the  MINILINKS  contract.  The 
purpose  of  this  installation  trial  was  to  allow  British  Aerospace 
Warton  to  assess,  from  practical  experience,  the  suitability  of  fibre 
bundle  technology  for  avionic  data  transmission.  The  emphasis  of 
these  trials  was  on  the  installation  of  fibre  optic  components  in  the 
most  realistic  production  conditions  possible. 

Marconi  Avionics  procured  a kit  of  parts  consisting  of  MINILINKS 
comptments  and  tools.  These  were  then  demonstrated  to  British 
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Aoi'osprtoo  pr«.Hluv'tion  jH'j'soiim'l  oonsistin^;  of  suporvisoi  s 

and  Inspectors.  I'his  production  team  then  wired  up  an  airframe 
metal  nuvkup  without  scientific  supervision.  These  trials  proved 
that  the  installation  of  fibre  optic  bundle  compv'uet'ts  constituted  no 
major  technical  risk  to  any  future  projects. 

3 MUl.Tl  ACX'KSS  NK'TWOHKS 

Theoretical  fibre  optic  network  configurations  liave  been  expounded 
for  a number  of  years.  The  advent  of  a widely  accepted  sfH'cific 
electrical  liijihway  standard  (Mil-Std-lfiftS)  and  the  solution  of  the 
eniiineerinp  problems  associated  witli  A-H  fibre  links  has  led  K.AHL 
to  the  formulation  of  a solution  to  allow  the  practical  implementation 
of  fibre  optic  multi  access  networks. 

3.1  KXlSTlNr,  NK  TWCMIK  t\'>NKU':UKA  T10NvS 

There  are  a number  of  configurations  beiiui  profH'sed  at  present, 
most  if  not  all  fall  into  the  two  categories  below.  The  following  text 
assumes  that  the  maximum  transmitter  to  receiver  .attenuation  for  a 
practical. military  standard. fibre  optic  system  is  apprv'ximately  32  dll. 

3.1.1  CKN  THAI.  STAH  OIS  TKIHU  TION 


The  central  star  distributor  is  a system  whereby  the  optical 
output  from  one  transmitter  is  optically  spbt  and  distributed  to  the 
other  network  terminals  by  means  of  a central  star.  KicT  3 shows  the 
basic  cmificiiration  for  two  terminals  in  a practical  avionic  32  way 
central  star  distributor.  Two  ile-mateable  connectors  have  been 
provided  at  each  system  I me  llepLiceable  Tint  (I  Kl’i  to  .lUow  normal 
first  and  second  line  mainteiunce.  The  central  star  is  shown 
cont.ained  in  an  I, HU  with  the  necessary  de -mateable  cvninectvirs . An 
in  line  bulkhead  connector  has  been  placed  in  each  arm  of  Hie  star  as 
Uiis  would  uiHloubteilly  be  necessary  in  an  aircraft  with  more  than  vine 
avionics  lx»y.  This  cvinfi^urati vui  wvnild  result  in  a transmitter  tvi 
receiver  attenuation  vif  greater  than  50  dU  atul  hence  is  luit  a practical 
proposition . 

This  cvuififiurativui  also  has  two  other  dis.idvantajjes . The  ci'iitral 
star  could  prixluce  a common  nuide  failure,  and  it  alsvi  results  in 
unnecessary  cable  lenjiths,  as  two  adjacent  l.HUs  would  communicate 
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via  the  central  star,  A central  star  distributor  system  of  about  ten 
terminals  is  feasible  in  the  avionic  situation  but  would  require  a 
concession  on  installation  practice,  as  the  central  star  and  all  the 
airframe  wirini?  would  have  to  be  supplied  and  installed  as  a preform- 
ed. one-piece  loom.  This  type  of  network  would  only  be  appropriate 
for  use  in  a sini^le  avionic  bay. 

3.1.2  OPTICAL  T HIGHWAY 

This  configuration  woxild  appear  to  be  suitable  as  it  has  the  same 
format  as  the  electrical  highway.  Fig  4 shows  that  when  all  the 
connectors  necessary  for  first  and  second  line  maintenance  have  been 
included,  this  configuration  results  in  very  high  transmitter  to 
receiver  attenuation.  The  main  factor  in  this  attenuation  is  the 
accumulated  insertion  loss  of  successive  T pieces.  This  configur- 
ation has  the  additional  disadvantage  that  its  implementation  would 
require  an  optical  receiver  with  a very  high  optical  attenuation  range, 

3.2  REGENERATIVE  MULTI  ACCESS  NETWORK 

Conventional  forms  of  fibre  optic  multi  access  network  were  found 
to  have  too  many  fundamental  problems  to  allow  the  rapid  implement- 
ation of  a Mil-Std-1553  fibre  optic  network.  FARL  have  approached 
the  problem  in  a different  manner.  The  only  other  alternative,  as 
networks  that  involve  passive  distribution  result  in  too  high  an 
attenuation  between  transmitters  and  receivers,  is  to  incorporate 
some  form  of  active  regeneration  of  the  optical  signal.  A network 
based  on  this  principle  has  been  designed  at  FARL,  and  is  known  as 
FOREMAN. 

3.2,1  foreman  - EXTERNAL  CONFIGURATION 

The  external  cabling  of  FOREMAN  is  restricted  to  the  use  of  A-B 
links.  This  gives  maximum  utilisation  of  component  development  and 
installation  experience,  thus  greatly  assisting  in  reducing  development 
timescales. 

The  only  method  of  implementing  a network  using  A-B  links  is  to 
form  a daisy  chain  where  each  avionic  unit  is  linked  to  its  immediate 
neighbours  by  a single  A-B  bi-directional  link.  The  disadvantage  of 
this  configuration  is  that  a failure  of  a single  cable  or  any  regeneration 
terminal  will  cause  a system  failure.  This  is  overcome  by  the 
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addition  of  redundant  links.  The  currently  preferred  confif^uration  is 
for  terminal  N to  have  direct  optical  access  to  terminals  N - 1,  and 
terminals  N - 2.  This  configuration  will  allow  the  survival  of  two 
cable  failures  and/or  one  terminal  failure.  It  should  be  noted  tliai 
this  is  the  minimum  failure  survival  cnpability,  as  more  failures  can 
be  survived  provided  they  are  not  adjacent. 

3.2.2  FOREMAN  - RASlC  FRINCIPI.E 

Fig.  5 shows  five  terminals  of  a FtiRFM.AN  system,  and  terminal 
N shows  the  basic  internal  elements  required  to  implement  it.  This 
particular  configuration  of  I’OHFM.AN  entails  any  terminal  having  an 
optical  path  to  the  four  adjacent  terminals,  thus  terminal^  is 
connected  by  a fibre  optic  cable  to  terminals  N - 1 and  N - 2.  It  can 
be  seen  from  the  diagram  that  the  four  cables  from  terminals  N - I 
and  N - 2 enter  terminal  N by  a 4 -way  connector.  The  four  cables 
are  then  joined  by  a four  way  Y.  the  main  stem  of  the  Y being 
coiuiected  to  a bi-directional  terminal. 

An  important  feature  to  note  is  ttiat  each  l.Hl'  only  has  one  active 
terminal  and  tluis  external  redundancy  is  gained  by  the  use  of  passive 
components. 

This  network  has  been  designed  for  Uie  transmission  of  pulses  of 
fixed  widtli.  Consider  tlie  case  of  the  optical  emitter  in  terminal 
N - 2 producing  a light  pulse  of  fixed  width.  This  pulse  would  be 
relayed  to  terminals  N.  N-1,  N-3  and  N-4.  Tlie  following  effect  wliicli 
will  be  described  in  detail  in  relation  to  terminal  N occurs  in  terminals 
N-1,  N-3  and  N-4  simultaneously.  Tlie  pulse  of  fixed  width  from 
terminal  N-2  enters  terminal  N via  the  4 -way  connector.  The  four 
way  Y routes  this  pulse  to  tlie  bi-directioivil  terminal.  When  the 
optical  detector  receives  this  pulse,  the  terminal  circuitry  will  cause 
the  optical  emitter  to  proiluce  a pulse  of  similar  widtli.  The  4-way 
Y will  cause  this  regenerated  pulse  to  be  conveyed  to  terminals  N - I 
and  N-2. 

The  pulse  conveyed  to  terminal  N-2  has  no  effect;  the  pulse 
conveyed  to  termitval  N-1  forms  tlie  redundant  link,  coinplemetitmg 
the  optical  pulse  transferred  between  termimls  N-2  and  N - 1 . I'he 
two  remaining  signals  are  conveyed  to  termiiuils  N f 1 and  N f 2. 

These  signals  will  cause  terminals  N + 1 and  N + 2 to  be  activated  by 
terminal  N in  the  same  manner  as  terminals  N-1  and  N when  activated 


by  terminal  N - 2.  Thus  the  ref^eneration  process  is  re-iterated  as 
many  times  as  is  necessary  for  the  orijjinal  light  pulse  to  be  conveyed 
to  all  the  terminals  (32  maximum)  in  the  network. 

A multi-access  network  tliat  is  capable  of  sending  short  pulses  of 
fixed  width  to  up  to  32  terminals  now  exists.  This  design  is 
compatible  with  existing  technology  and  aircraft  installation  practices. 
Fig  5 shows  that  the  minimum  FXiREMAN  configuration  has  an  optical 
attenuation  of  20.5  dB.  This  leaves  an  11.5  dB  nvargin  on  the  82  dB 
maximiun  transmitter  to  receiver  attenuation  allowable  in  a military 
standard  system. 

Mil-Std-1553  utilises  Manchester  encoding  which  has  led  to  Uie 
development  of  a modulation  technique  which  allows  a Manchester 
encoded  signal  to  be  relayed  using  pulses  of  fixed  widtli.  This 
modulation  technique  also  allows  the  bi -phase  signal  (3rd  state)  to 
be  encoded,  thus  achieving  complete  compatibility  with  a Mil-Std-1553 
system. 

3.2.3  FOREMAN  - REMOTE  TERMINAL  INTERK.-VCK 

The  FOREMAN  terminal  contains  the  analogue,  digital  and  optical 
components  required  to  replace  the  electrical  data  transmission 
components  in  a Mil-Std-1553  system.  The  point  at  which  l'\'>RKM.AN 
interfaces  with  the  Remote  Terminal  is  flexible.  The  implementation 
of  FOREM.\N  would  automatically  replace  the  data  bus  cabling,  the 
coupling  transformer  and  the  stub  cable. 

Fig  tl  shows  tl\e  optimum  method  of  interfaciivi  the  FORKM.AN 
system  wiUi  a remote  terminal.  The  R'tREMAN  terminal  interfaces 
directly  with  such  components  as  the  Harris  Manchester  Encoder 
Chip  or  any  future  1553  LSI  chip  sets,  thus  replacing  tl\e  isolatioi\ 
transformer  and  the  transformer  driver. 

Fig  7 illustrates  an  alternative  method  of  interfacing  which  could 
be  useful  for  development  purposes.  The  Ft  Hi  EM  AN  termiiwl  is 
located  in  a small  additional  LRB  and  is  connected  to  the  isolativ>n 
transformer  in  the  system  LRB.  This  would  allow  FOREMAN  to  be 
used  on  an  electrical  1553  system  with  minimal  modification  to  exist- 
ing hardware. 
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4 CONCLUSION 


FOREMAN  is  a fibre  optic  multi  accet.  - network  which  is  fully 
compatible  with  Mil-Std-1553 . The  use  of  FOREMAN  only  requires 
a chanije  in  the  data  transmission  components  leaving  all  the  remote 
terminal  loeic  and  subsystem  unchaneed.  The  maximum  use  of 
existing  technology,  results  in  FOREMAN  beinp  a low  risk  system 
which  is  capable  of  rapid  implementation. 
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AN  AIRCRAFT  1553B  COMPATIBLE 
FIBER  OPTIC  INTERCONNECT  SYSTEM 
Robert  Betts 

IBM  Federal  Systems  Division 
Owego,  NY  13827 


This  paper  describes  the  tradeoffs  made  and  the  compon- 
ents and  configuration  selected  to  implement  a fiber  optic 
1553B-compatible  data  bus.  The  basic  assumption  of  near-term 
application  and  MIL-E-5400  environments  restricted  the  choice 
of  components  and  technology  to  that  presently  available. 

Among  the  system  elements  examined  and  traded  off  were  sources, 
detectors,  fiber  type,  single  or  bundle  cable,  connectors, 
optical  couplers,  optical  waveforms,  and  transmitter  and  re- 
ceiver electronics.  To  be  compatible  with  MIL-STD-1553B  re- 
quired selection  of  some  "standard"  electrical  interface 
available  in  existing  equipment  to  minimize  any  required 
retrofit  modifications.  Such  an  interface  is  where  the  data 
has  been  encoded  in  two-level  Manchester  format.  A conclus- 
ion of  the  studies  was  that  a pulse  position  modulated  opti- 
cal waveform  can  improve  significantly  the  system's  signal- 
to-noise  ratio  and  can  be  used  to  improve  the  bit  error  rate 
or  to  increase  allowable  worst-case  losses. 

Examination  of  MIL-STD-1553A  and  its  imminent  successor 
1553B,  shows  that  implementation  of  a fiber  optic  inter^-on- 
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nection  scheme  to  replace  the  twisted  shielded  pair  trans- 
mission medium,  without  major  effect  on  the  standard,  re- 
quires making  the  fiber  optics  transparent  to  the  protocol 
and  bus  architecture.  This  can  be  done  by  selecting  the  pro- 
per electrical  interface  in  the  transmitter  and  receiver 
electronics  such  that  the  system  is  unaware  of  whether  the 
bus  is  wire  or  glass.  Such  an  interface  is  where  the  digital 
information  put  on  or  received  from  the  bus  is  a two-logic- 
level  Manchester-encoded  signal.  Figure  1 is  a block  dia- 
gram showing  both  interfaces  and  the  required  electrical 
waveform.  This  interface  exists  or  will  exist  in  any  equip- 
ment that  conforms  to  MIL-STD-1553B. 
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Figure  1.  Two-Level  Manchester  In  or  Out 

The  first  priority  in  the  initial  studies  was  to  survey 
the  existing  market  for  optical  and  electro-optical  components 
or  technologies  which  were  qualified  or  could  be  qualified  to 
the  military  environment;  in  particular,  meeting  the  tempera- 
ture, humidity,  and  reliability  requirements.  This  narrowed 
the  field  to  large  physical  aperture  LEDs  (light-emitting 
diodes) . Lasers  have  three  problems;  (1)  their  lifetime 
has  not  been  sufficiently  proven,  (2)  they  require  temperature 
stabilization  in  military  environments,  and  (3)  they  are  only 
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i-'ompat  ib  lo  with  s inq  lo- f ilu'f  aysti'ins,  and  location  of  t ho 
oxtronu'ly  small  omitt-inq  aroa  roqiiiros  a piqtailod  paokaqc* 
which  as  yot  has  not  boon  dovolopod  to  t ho  point  whoro  t.rno 
liormot  ic  i tv'  has  boon  acliiovod. 

LF.Ds  como  in  various  forms.  To  minimizo  tho  couplinq 
loss  at  tho  input  to  tho  f ibor  bus  systom,  ai\  optically  en- 
hanced device  (use  of  a Ions  or  reflector  in  tho  LKH  cliip 
packaqinq)  appeared  to  offer  siqni f icant ly  bettor  couplinq 
than  nonenhancod  types.  Havinq  selected  tho  omittiM'  of  t lu' 
optical  bus  systom,  tht'  next  task  was  to  determine  tho  op- 
t inmm  combinations  of  cable,  connectors,  couplers,  and  de- 
tectors. The  "best"  sinq I e-e lement  selection  does  not  nec- 
essarily imply  the  optimum  system.  It  is  the  best  combination 
of  elements  that  must  be  selected. 

A loqical  place  to  start  is  to  establish  what  is  calU'd 
the  system  loss  budijet  in  view  of  other  requirements.  Mll.- 
STn-ir)r>,lA  and  H require  an  undetected  error  rate  of  I x 10“'*. 
This  requires  a qood  siq!\al-to-i\oise  ratio  at  the  outpvit  of 
the  receiver  elect roi\lcs , where  the  decision  for  a "I"  or 
"0"  is  to  be  made.  Ml  I.-STD- 1 fiS-lA  and  B also  require  a bus 
with  iqi  to  32  jK>rts.  It  vjuickly  becomes  obvious  that  a rad- 
ial or  "star"  optical  coupler  is  required  to  minimi/e  the 
system  losses  without  resort inq  to  active  couplinq  means 
that  would  detract  from  system  reliability.  In  the  star 
coupler,  there  is  an  unavoidable  power  division  loss  in  jK'>wer 
decibels  (dh)  of  10  loq  P where  P is  the  nun\l>er  of  jmets  in 
the  system.  For  32  ports  this  loss  is  15  dP  and  for  Ih  viorts, 
12  dU. 

A coiwent ion  for  comparinq  optical  receiver  capability 
is  to  describe  its  sensitivity  in  dBm.  Plus  or  minus  dBms 
are  dBs  above  or  below  1 mW  of  optical  jH^wer.  'IVo  types  of 
optical  detectors  have  the  speed  atul  sensitivity  required  for 
this  application.  They  are  the  silicon  PIN  photodiode  .»nd 
the  silicon  avalanche  photodiode  (PIN  and  APO  respectively). 

The  PIN  diode  has  a limit  of  arovmd  -43  dBm  sensitivity  and 
the  APO  about  -65  dBm  for  a one-to-one  siqnal-to-rms-iK'>ise 
ratio.  For  a 10“^2  bit  error  rate  (BFR) , one  requires  ap- 
proximately 14.5  to  1 siqna l-to-rms-noi se  level  at  the  decision 
ix'>int  for  "Is  and  "Os".  This  translates  to  11.6  dB  above  the 
noise.  Addinq  this  to  the  diode  limits,  one  must  supply  at 
least  -31.4  dBm  to  tho  PIN  receiver  and  -53.4  dBm  to  the  APP 
receiver.  A qood  fiqure  for  the  output  of  an  optically  en- 
hanced I.KP,  takinq  into  account  temperatvire  and  aqinq  is  -3 
dBm.  Table  1 shows  the  maximum  allowable  loss  in  the  remainder 
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of  n bus  syatt'iii  for  lb  ixjrta  niul  32  porta  for  a PIN  aiul  an  Al'P 
dotoctor  (detector  sensitivity  minus  emitter  power  minus  oovjplet 
division  loss) . 

Table  1.  Maximum  Allowable  U'»aa 


PIN 

API) 

lb 

32 

ports  lb. 4 
l>orts  11.4 

illl 

dll 

(13.4) 

(10.4) 

311.4  dll 

15.4  dll 

(15.4) 

(12.4) 

In  todays  state  of  the  art,  theje  is  an  additional  i>\- 
sertion  loss  in  star  coviplers  of  approximately  t ud  liue  to  non- 
uniformity, reflections,  et-^.  If  this  is  svjbtraoted  from  the 
abov'e  table,  the  fiqures  in  parenthesis  apv'ly.  These  nvimbers, 
then,  represent  losses  that  are  allowed  foj-  input  and  ovitput 
oouplinq,  connectors,  and  the  fiber  optic  cable  itself . It 
wi.'>uld  appear  that  selection  of  the  ATP  leceiver  was  obvious, 
but  other  considerations  svjch  as  ttsuperat  vne  sei\a  i t i v i t y atAd 
the  hiqh  voltaqe  (^200  V)  required  for  operat  io\^  ot  an  Al'P 
would  favor  the  PIN  diode  if  it  could  satisfy  the  bus  ttniuirc’- 
monts.  The  next  task  was  the  tradeoffs  betweeii  i>\pvit  and 
output  coviiUinq  and  connector  loss  auaii\st  the  cable  oonfivi- 
viration  and  optical  fiber  selection.  Takinq  cost  aiui  ro- 
quiremeiAts  into  account,  anil  ar.sumini)  t lu'  viri'ati'st  ilistatn'i' 
between  terminals  on  the  bus  as  100  metc'rs,  it  was  clear  that 
fiber  with  losses  in  the  rai\qe  ot  10  ti'  <10  ilH  pi'j  km  wim  i'  ri'- 
quired . 

A set  of  computer  pro«irams  were  wrilti'n  for  calcvilatinu 
the  inp\it  couplinq  loss,  the  oulinit  covipliiwi  Uv^s,  the  v'on- 
nector  toss,  and  the  system  loss  fiu'  best  at\il  WiMst  cast'  CkMU- 
binations  of  variovjs  emitters,  detectors,  cabl«',  anil  Ci'nni'i'tiM 
Ci)nf  iquratioi\s . Variables  in  tlu'se  calculat  ii>ns  wovi'; 

• liEP  source  (aperture)  si/e 

• Radiation  pattertt  (ciisine  expi>iu'nt  ) 

• F i be r il  i anu' t o r and  t o I e r a tii-e 

• Fiber  bundle  siv’.e 

• Core-clad  ratio  of  fiber 

• Number  of  fibers  in  bvindle  (hexavioual  pattetui  assumeil) 

• Source-bundle  ta'lative  piuution 

(off-axis,  rotatii'n,  ainile,  spaciitvj) 

• Core  refractivi'  itidex  ( i t'f  1 ect  ioi\  loss) 

• Core  numcMical  aperture  (N  A) 


808 


Connector  bundle-bundle  relative  position 
(off-axis  rotation,  angle,  spacing) 
Direction  through  connector 
Detector  size 

Bundle-detector  relative  position 

(off-axis,  rotation,  angle,  spacing) 
Number  of  connectors 
Number  of  ports  on  bus 
Output  power  of  source 
Distance  between  terminals 
Cable  end  finish  quality 
Cable  loss. 


Preliminary  results  of  the  computer  calculations  established 
two  of  the  many  choices  to  be  made.  First,  it  was  obvious 
that  to  hold  the  input  coupling  loss  to  a reasonable  value, 
the  optically  enhanced  LED  and  a fiber  bundle  cable  were 
impel ative.  The  source  physical  aperture  of  available  infra- 
red (for  speed)  LEDs  was  arovind  1.2  mm,  and  the  compatible 
bundle  cable  was  19  fibers  in  a hexagonal  pattern  with  a 
fiber  core  diameter  of  215  iim.  Seven  fibers  at  360  urn  was  a 
possible  choice,  bv\t  for  cable  flexibility  and  bend  radius, 

19  was  chosen.  Thirty-seven  fibers  at  150  iim  (another  vv>s- 
sibility,  was  rejected  because  of  cable  cost. 

After  many  iterations  and  tradeoffs,  the  final  configuration 
was  chosen.  Table  2 shows  all  of  the  variables  and  assumed 
tolerances,  with  the  final  typical,  minimum,  and  maximum  sys- 
tem losses  along  with  the  dynamic  range  requirements  of  the 
optical  receiver.  Not  shown,  but  assvimed,  was  a transmissive 
type  star  coupler  to  avoid  the  additional  3 dn  in  a reflective 
coupler  required  at  the  terminal  end  of  the  cable  to  separate 
transmitter  and  receiver  paths. 

For  typical  systems  within  these  constraints,  a PIN  di'tector 
offers  adequate  margin  for  required  signal-to-noise  ratios. 

The  worst  case  shown,  although  [x^'ssible,  is  vei  y improbable 
because  of  the  required  coincidence  of  all  the  elemental 
worst  cases.  However,  deviations  from  typical  most  certainly 
will  occur,  and  any  decrease  in  loss  or  increase  in  optical 
power  without  a relatively  corres^xjnding  increase  in  noise 
will  enhance  the  orobability  of  maintaining  the  required  bit 
error  rate  of  10“i2. 


Various  optical  waveforms  were  investigated.  A three- 
level  Manchester  as  in  the  twisted-pair  1553A  standard,  a 
tvro-level  zero-to-plus  Manchester,  and  a pulse  ^visition 


Table  2.  Final  System  Loss  Analysis 


modulation  (PPM)  easily  encoded  from,  and  decoded  to  the  Man- 
chester interfaces  shown  in  Figure  1.  Figure  2 shows  the  first 
few  bits  of  a conunand  word  of  the  1553A  protocol  encoded  in  the 
three  forms.  Both  the  three  and  two  level  Manchester  were  re- 
jected in  favor  of  the  pulse  modulation  because  of  the  gains 
achievable  to  be  described  in  the  following  paragraphs. 

There  are  three  potential  advantages;  (1)  a gain  in  sig- 
nal-to-noise  ratio  of  the  square  root  of  the  relative  ampli- 
tudes of  the  short  pulse  to  a conventional  average  50%  duty 
cycle  Manchester;  (2)  a constant  non-variable  threshold  level 
at  the  decision  point  for  "Is"  and  "Os"  in  the  receiver,  and 
(3)  a simple  way  to  handle  the  dynamic  range  of  detector  input 
power  caused  by  differences  in  highest  and  lowest  loss  paths 
between  terminals  on  the  bus. 

For  the  following  derivations  and  for  comparison  with 
other  systems,  two  assumptions  will  be  made;  (1)  the  princi- 
pal source  of  noise  is  in  the  receiver  preamplifier,  and  (2) 
the  noise  is  white  gaussian  in  nature.  These  assumptions 
are  compatible  with  previous  papers  on  the  subject  and  are 
also  real  in  terms  of  the  systems  and  bandwidths  involved. 
Figure  3 shows  the  type  of  pulse  examined  along  with  defin- 
itions of  amplitude  and  normalized  time.  Figure  4 shows  the 
receiver  bandpass  characteristics  along  with  a low-frequency, 
f^f  and  high-frequency,  fq,  cutoff  at  the  3 dB  and  3 or  6 dB 
point  respectivelv'. 

The  auto-correlation  function  for  Gaussian  white  noise 
after  the  receiver  "filter"  is: 


RQ(t)  = 0 J h(u)-h  (u+  jt|  ) du 

o 


where  h is  the  receiver  impulse  response,  and  0 is  the  noise 
power  per  unit  frequency. 

From  this  it  follows  that  the  standard  deviation  in  rms  noise 
is : 


..f.i 


lh(u)]  du 


o = rms  noise  at  receiver  output. 
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Figure  3.  Amplitude  as  a Function  of  Normalized  Time 


A f igure-of-merit 
as : I 


FOM  = — 
0 


(FOM) 


for  this  pulse  system  can  be  chosen 


where  A'  is  the  pulse  amplitude  at  the  receiver's  output. 

Substituting  for  a,  and  multiplying  numerator  and  denominator 
by  Ayj  ti 


FOM  = 


where  A is 


yfh  'yjfiti  • A* 

VT"  AJti  f lh(t)]^dt 

^ 0 

the  input  pulse  amptitude  tj  is  the  pulse  width. 
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Figure  4.  Receiver  Bandpass  Characteristics 


To  maintain  a constant  energy  pulse  to  keep  the  tempera- 
ture  rise  in  the  LED  junction  from  degrading  its  performance 
or  lifetime,  the  product  At^,  must  be  kept  constant.  Since 
for  a given  receiver,  0 is  a constant,  we  can  write  the  last 
equation  as: 

FOM  = C • 


where  A^  is  a normalized  output  s 1 and  C 

It  follows,  then,  that  the  FOM  is  a function  of  the  re- 
ceiver bandpass  characteristics,  the  pulse-width,  and  the 
input  amplitude.  The  significant  factor  here  is  the  gain  in 
FOM  by  the  square  root  of  the  input  pulse  amplitude.  It  also 
turns  ovit  that  for  a given  pulse  width  and  duty  cycle,  there 
is  arf'optimum  bandpass  with  a precisely  located  upper  and 
lower  cut-off  frequency  to  give  the  maximum  FOM. 
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When  comparing  a normal  50%  average  duty  cycle  Manchester 
with  the  PPM  system  using  a 50-ns  pulsewidth  for  a l-MHz  bit 
rate,  the  term  for  both  systems  when  optimized  for  bandwidth 
is  about  the  Scune  ( = 0.85).  However,  with  a 50-ns  pulse,  one 
can  allow  an  increase  of  10  times  the  amplitude  for  a factor 
of  VIO  or  + 5 dB  of  peak  power  or  peak  signal -to-noise  ratio. 
For  LEDs,  in  their  normal  operating  range,  this  requires  a 1-A 
pulse  50  ns  wide.  Pulse-widths  much  less  than  50  ns  require 
very  fast  LEDs  and  correspondingly  more  difficult  peak  currents 
to  generate.  The  pulse  was  therefore  limited  in  this  study  to 
50  ns  and  1 A.  Dr.  J.R.  Biard  of  Spectronics  has  performed 
an  analysis  in  a paper  "Thermal  Transients  in  Light-Emitting 
Diodes,"  which  shows  that  1-A,  50-ns,  5%  duty-cycle  pulses 
maintain  the  same  junction  temperature  rise  as  a 0.1  A 50% 
duty-cycle  pulse.  He  maintains  this  will  preserve  conditions 
that  will  not  degrade  the  life  of  the  device. 

A fourth  advantage  of  PPM  not  mentioned  before  is  the  com- 
patibility with  a natural  operating  mode  of  lasers.  When  semi- 
conductor laser  technology  has  matured,  the  emitter  can  be 
easily  replaced  by  a laser  with  minimum  modifications  to  the 
system  and  gain  additional  dB  through  the  V~A  factor. 

The  equation  for  FOM  involving  constant  At^  and  the  VX 
improvement  verify  conclusions  reached  in  the  literature  that 
the  narrower  the  pulse  the  better. d) 

A further  advantage,  as  previously  stated,  is  the  fact 
that  with  the  bandwidths  involved,  the  receiver  has  essentially 
recovered  between  pulses  such  that  a changing  threshold  for 
1/0  decisions  is  not  required  because  of  the  dynamic  range 
as  is  required  in  the  50%  duty  cycle  case.  One  sets  the 
threshold  for  the  minimum  signal  and  leaves  it  there. 

A third  advantage  related  to  the  second  is  the  method  for 
handling  the  large  dynamic  signal  range.  To  adjust  the 
threshold  levels  in  the  50%  duty  cycle  case,  a fast  AGC  sys- 
tem is  required  since  the  threshold  must  be ‘ set  in  the  middle 
of  the  signal  amplitude.  In  the  case  of  the  short  pulse,  the 
threshold  is  constant  and  all  that  need  be  done  is  to  compress 
the  high  signal  levels  with  techniques  such  as  logarithmic 
amplifiers  or  networks. 

As  to  bit  error  rate  (BER) , the  following  derivations  for 
the  PPM  approach  show  the  required  signal-to-noise  levels  and 
the  placement  of  the  threshold  at  the  1/0  decision  point. 


In  the  PPM  system  we  are  concerned  with  two  types  of 
errors;  the  probability  of  a missed  detection  and  the  proba- 
bility of  a false  alarm. 


The  differential  false  alarm  probability,  dp,  that  the  noise 
exceeds  some  threshold,  ka  (o— rms  noise) , between  a time 
t and  (t  + dt)  is: 


where  J is  defined  as  the 
pass  noise  spectrum  and  is 


f = 


L/f^co 


(f)df 


J 0o(f)df 


average  frequency 
given  by: 


of  receiver  band- 


where  is  the  Fourier  transform  of  the  noise  autocorre- 

lation function  Ro(t)  given  before  and  is  therefore  the  spec- 
trum of  noise  in  the  filter  output.  The  average  number  of 
threshold  crossings,  P,  in  time  t is: 


dt 


If_we  normalize  time  as  in  Figure  3.,  and  define  a term  x = 
2itfT  where  T is  the  reciprocal  of  the  average  pulse  repitition 
frequency,  then: 


and  P = ^ 
2it 


E for  a = 


1 


where: 


[h* (t)]^dt 
[h(t) ]^dt 
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where  h(.t)  is  the  impulse  response  of  the  receiver  and  h'  (t) 
is  its  first  derivative. 

The  equation  for  P describing  the  average  number  of  thres- 
hold crossings  in  time  t did  not  limit  the  duration  of  the 
threshold  crossing.  Since  the  1/0  decision  in  reality  is  a 
function  of  the  electronic  response  of  the  decision  making 
circuit,  the  noise  must  remain  some  minimum  time,  to,  above 
the  threshold  in  order  for  a false  alarm  to  occur.  The  true 
false  alarm  probability  Pfa  is  therefore; 


X 2 

P,^  = P'  . P = P'  . e 
fa  2tt 

where  P'  is  the  conditional  probability  that  if  the  noise  ex- 
ceeds the  threshold  ka,  it  will  stay  above  it  for  at  least  a 
time  duration  tQ.  Reference  (2)  gives  an  equation  for  P'  as: 

- i (irft  k)2  - i (xt  k/2T)^ 

P'  S e ° = £ ^ ° 


The  false  alarm  probability  is  therefore; 


j - i [1  + (xty2T)2] 
17  ^ 


Or,  for  a given  Pj^/  the  threshold,  ko , must  be  set  at: 


ka  = 0 


2(in^  - InP^J 


fa' 


1 + 


(y^)' 


The  probability  of  a missed  detection,  Pn\^»  is; 

P j = Probability  that  [A'  +n{t)  ] < ka  for  some  time  t in  the 
interval  tQ.  Since  n(t)  is  the  Gaussian  variable  with  stand- 
ard deviation  a,  then; 


where  A = — (A'  - ka) 
a 

This  is  the  well  known  error  function,  erfc. 


i 

■4 


r 


'i 


^ -V 


In  a 1553B  bus  system  using  PPM,  the  average  pulse  spacing 
during  a transmission  is  1 us.  Under  these  conditions  with  a 
pulsewidth  of  50  ns,  the  bandwidth,  and  upper  and  lower  cutoff 
frequencies  are  8.4,  8.8,  and  0.4  MHz  respectively.  From  the 
previous  equations  for  Pf^  and  if  it  is  desired  that  the 

BER  should  be  10~12,  then  the  threshold,  ka,  must  be  7.15n  for 
false  alarms  and  the  pulse  amplitude.  A',  must  bo  7.03a  + 7.15n 
= 14.18a.  This  is  a limiting  value  since  false  alarms  do  not 
occur  during  pulses,  and  pulses  have  finite  widths  greater  than 
the  response  times  of  the  decision  circuitry.  It  is  addition- 
ally pessimistic  since  it  does  not  take  into  account  detection 
of  errors  by  parity. 

The  threshold  and  pulse  amplitudes  for  a SO*?,  duty  cycle 
straight  Manchester  are  about  the  same.  However,  it  should 
be  remembered  that  the  PPM  pulse  using  LEDs  can  achieve  10 
times  the  amplitude  and  therefore  have  an  advantaiie  of  VlO  or 
+5  dB  in  signal-to-noise  ratio  and  +10  dD  in  terms  of  ampli- 
tude. This  will  add  10  dBm  to  the  detector  powt'rs  in  Table  2 
under  system  losses. 

The  transmitter  and  receiver  circuitry  are  relatively  sim- 
ple and  straightforward.  Figure  5 is  the  schematic  of  the 
transmitter  circuitry.  Use  of  a VMOS  power  FET  to  switch  a 
high  current  through  the  LED  supplied  from  the  energy  stored 
in  the  capacitor  C allows  very  fast  risetimes.  The  resistor, 
Ry,  is  a negative  temperature  coefficient  device  which  allows 
charging  the  capacitor  C to  higher  voltages  as  the  temperature 
rises,  thereby  offsetting  the  temperature  characteristics  of 
the  VMOS  and  LED  and  tending  to  maintain  a constant  light 
output  from  the  LED  with  temperature. 

Figure  6 is  a block  diagram  of  the  receiver  circuit.  Tlie 
preamplifier  is  a transimpedance  amplifier  with  a gain  of  2.2 
kii.  The  postamplifier  is  a differential  amplifier  with  a i|ain 
of  10.  The  low-frequency  cut-off  is  implemented  at  the  post- 
amplifier input  with  the  RC  coupling  time  constant.  Two 
stages  of  amplification-compression  follow  the  postamplifier. 
Figure  7 is  a detailed  schematic  of  one  stage. 

T1  and  T2  together  form  a differential  amplifier  with  a 
maximum  pulse  output  of  4 V.  T3  is  an  emitter  follower  drivi'P, 
by  the  differential  amplifier,  and  at  high  levels  it  causes 
enough  current  through  diode,  D2,  to  make  it  a low  impedance 
compared  to  R2  and  Ri  such  that  the  output  never  gets  beyond 
about  0.8  V with  up  to  4 V signal  at  the  base  of  T3. 

With  a 20-dB  dynamic  range  in,  this  circuit  will  compress 
the  range  to  around  11  dB.  A second  stage  after  amplification 
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Filjure  7.  Amplifier  - Compressor  Schematic 

of  the  0.8  V to  4 V will  further  compress  to  a 4 or  5 dn 
dynamic  ranqe  that  can  easily  be  handled  in  the  comparator 
with  a constant  reference  set  for  the  minimum  siqnal  level. 

In  summary,  the  reconmu'nded  implementation  of  a fiber 
optic  155  311  - compatible  d,ita  bus  interconnect  system  is  as 
fo 1 lows : 

Spectronics  SK2231  LKD  or  equiva- 
1 ent 

21  5-11  m core  PCS 

19  fibers  in  ruqqedized  sheathiiui 

Hexaqonally  packed  stripped  and 
thinly  reclad  fibers  with  keyed 
connection . 

Ill-port  transmissive  stai' 


S20 


• Detector: 


1 


• Optical  Waveform: 


• Transmitter: 


• Receiver: 


Spectronics  SE2232  PIN  photodiode 
or  equivalent 

PPM  Manchester  (a  50-ns  pulse  for 
every  500  ns  the  two-level 
Manchester  is  at  an  up  level) 

A driver  to  furnish  a 1-A  pulse  to 
the  LED  and  driven  by  the  PPM  en- 
coded data  at  TTL  logic  levels. 

Trans impedance  preamp,  postamp,  two 
stages  of  amplification  and  dynamic 
range  compression,  into  a high- 
speed comparator  with  TTL  logic 
levels  out. 


• Min.,  typical. 

Max. , detector 

power ; -33.1  dBm,  -19.6  dBm,  -9.9  dB. 


This  paper  has  described  the  effort  in  performance  of  a 
contract  to  IBM  Federal  Systems  Division  from  the  Naval  Ocean 
System  Center  in  San  Diego,  California. 
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1 . SCOPE 

1.1  Scope . This  standard  establishes  requirements  i'or  digital, 

Qcxnmand/ response  , time  division  multiplexing  (Data  bus)  techniques  on  aircraft. 
It  encompasses  the  data  bus  line  and  its  interface  electronics  illustrated  on 
figure  1,  and  also  defines  the  concept  of  operation  and  information  flow  on  the 
multiplex  data  bus  and  the  electrical  and  functional  formats  to  be  employed. 

1.2  Application . hhen  invoked  In  a specification  or  statement  of  work,  these 
requirements  shall  apply  to  the  multiplex  data  bus  and  associated  equipment 
which  is  developed  either  alone  or  as  a portion  of  an  aircraft  weapon  system  or 
subsystem  development.  The  contractor  is  responsible  for  invoking  all  the 
applicable  requirements  of  this  Military  Standard  on  any  and  all  subcontractors 
he  may  employ. 

2.  HEKEHENCED  DOCUMENT'S 

2.1  Issue  of  document.  The  following  document,  of  the  issue  in  effect  on  date 
of  invitation  for  bid  or  request  for  proposal,  forms  a part  of  the  standard  to 
the  extent  specified  herein. 

SPECIFICATION 

MILITARI 

MIL-E-6O51  Electromagnetic  Compatibility  Requirements,  Systems 

(Copies  of  specifications,  standards,  drawings,  and  publications  required  by 
contractors  in  connection  with  specific  procurement  fun''tlons  should  be 
obtained  from  the  procuring  activity  or  as  directed  by  the  contracting 
officer .) 

3.  DEFINITIONS 

3.1  Bit . Contraction  of  binary  digit:  may  be  either  zero  or  one.  In 
information  theory  a binary  digit  is  equal  to  one  binary  decision  or  the 
designation  of  one  of  two  possible  values  or  states  of  anything  used  to  store 
or  convey  information. 

3.2  bit  rate.  The  number  of  bits  transmitted  per  second. 

3.3  Pulse  code  modulation  (PCM).  The  form  of  modulation  in  which  the 
modulation  signal  is  sampled,  quantized,  and  coded  so  that  each  element  of 
information  consists  of  different  types  or  nimbers  of  pulses  and  spaces. 

3. 'I  Time  division  multiplexing  (TDM).  The  transmission  of  information  from 
several  signal  sources  through  one  communication  system  with  different  signal 
samples  staggered  in  time  to  form  a composite  pulse  train. 

3.5  Half  duplex.  Operation  of  a data  transfer  system  in  either  direction  over 
a single  line,  but  not  in  both  directions  on  that  line  simultaneously. 

3.6  i(prd<  In  this  docunent  a word  is  a sequence  of  16  bits  plus  sync  and 
parity.  There  are  three  types  of  words:  command,  status  and  data. 
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3*7  Mcaaftae . A single  message  Is  the  transmission  of  a command  word,  status 
word,  and  data  wirds  If  they  are  specified.  For  the  case  of  a remote  terminal 
to  remote  terminal  ( HT  to  HT)  transmission,  the  message  shall  Include  the  two 
command  words,  the  two  status  words,  and  data  wcrxls. 

3*8  Subavatem.  The  device  or  functional  unit  receiving  data  transfer  service 
from  the  data  bus. 

3.9  Data  bus.  Whenever  a data  bus  or  bus  is  referred  to  in  this  document  It 
shall  imply  all  the  hardware  Including  twisted  shielded  pair  cables.  Isolation 
resistors,  transformers,  etc.,  required  to  provide  a single  data  path  between 
the  bus  controller  and  all  the  associated  remote  terminals. 

3-  10  Terminal . The  electronic  module  necessary  to  Interface  the  data  bus  with 
the  subsystem  and  the  subsystem  with  the  data  bus.  Terminals  may  exist  as 
separate  line  replaceable  units  (LHU's)  or  be  contained  within  the  elements  of 
the  subsystem. 

3>11  Bus  controller.  The  te.-mlnal  assigned  the  task  of  Initiating  Information 
transfers  on  the  data  bus. 

3*12  Bus  monitor.  The  terminal  assigned  the  task  of  receiving  bus  traffic  and 
extracting  selected  Information  to  be  used  at  a later  time. 

3*13  Hemote  terminal  (HT).  All  terminals  not  operating  as  the  bus  controller 
or  as  a bus  monitor. 

3> 14  Aavnchronoua  operation.  For  the  purpose  of  this  standard,  asynchronous 
operation  is  the  use  of  an  Independent  clock  source  in  each  terminal  for 
message  transmission.  Decoding  Is  achieved  In  receiving  terminals  using  clock 
information  derived  from  the  message. 

3-15  Dynamic  bus  control . The  operation  of  a data  bus  system  In  which 
designated  terminals  are  offered  control  of  the  data  bus. 

3>16  f-omnqfnd/RBSDQnse . uperation  of  a data  bus  system  such  that  remote 
terminals  receive  and  transmit  data  only  when  commanded  to  do  so  by  the  bus 
control ler . 

3*17  Redundant  data  bus.  The  use  of  more  than  one  data  bus  to  provide  more 
than  one  data  path  between  the  subayst(<ms,  l.e.,  dual  redundant  data  bus, 
trl-redundant  data  bus,  etc. 

3*18  Broadcast . Operation  of  a data  bus  system  s(x.'h  that  Information 
transmitted  by  the  bus  controller  or  a remote  teimlnal  Is  addressed  to  more 
than  one  of  the  remote  terminals  connected  to  the  data  bus. 

3-19  Mode  code.  A means  by  which  the  bus  controller  can  communicate  with  the 
multiplex  bus  related  hardware,  in  order  to  assist  In  the  management  of 
information  flow. 
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>t.  GbINKHAL  Hl!;gUlHUlb,NTS 

M.  1 Test  and  operatlnK  reuulrecnents . All  requirements  as  specified  herein 
shall  be  valid  over  the  environmental  I'ondltlons  which  the  multiplex  data  bus 
system  shall  be  required  to  I'perate. 

*1.2  Data  bus  operation.  The  multiplex  data  bus  system  in  its  most  elemental 
confij^uration  shall  be  as  sitown  on  fi^^ure  1.  The  multiplex  data  bus  system 
shall  function  asynchronously  in  a command/ response  mode,  and  transmission 
shall  occur  in  a half-duplex  manner.  Sole  control  of  information  transmission 
on  the  bus  shall  reside  with  the  bus  controller,  which  shall  Initiate  all 
transmissions.  The  infonnation  i'low  on  the  data  bus  shall  be  comprised  of 
messages  which  are,  in  turn,  formed  by  three  types  of  wc<rds  (command,  data,  and 
status)  as  defineil  in  **.  3.3.5s. 

*«.  3 Charaoterlstics 

*1.3.1  Data  form.  Digital  data  may  be  transmitted  in  any  desired  form, 
provided  that  the  chosen  form  shall  be  compatible  with  the  message  and  word 
formats  defined  in  this  standard.  Any  unused  bit  pt^sitlons  in  a word  shall  be 
transmitted  as  logic  zeros. 

**.3.2  Bit  priority.  The  most  significant  bit  shall  be  transmitted  first  with 
the  less  significant  bits  following  in  descending  otxler  o(  value  in  the  data 
word.  Ttie  number  of  bits  required  to  define  a quantity  shall  be  consistent 
with  the  resolution  or  accuracy  required.  In  the  event  ttiat  multiple  precision 
quantities  (InfonnatVon  accuracy  or  resolution  requiring  more  than  16  bits)  are 
transmitted,  the  most  significant  bits  siiall  be  transmitted  first,  followed  by 
the  word(s)  containing  the  ^esser  signli'lcant  bits  in  nimerical  descending 
order,  bit  packing  of  multiple  quantities  in  a single  data  word  is  permitted. 

*4.3.3  IranqmAaalgn . 

*4.3.3.  1 Modulation . The  signal  shall  be  transterretl  over-  the  data  bus  in 
serial  digital  pulse  code  modulation  form. 

*4. 3-3. 2 Data  code.  The  data  code  shall  be  Manchester  11  bl-pliase  level.  A 
logic  one  shall  be  transmitted  as  a bipolar  coded  signal  t /()  (l.e.,  a positive 
pulse  followed  by  a negative  pulse)  . A logic  zero  shall  be  a bipolar  coded 
signal  0/1  (l.e.,  a negative  pulse  followed  by  a positive  pulse).  A transition 
through  zero  occurs  at  the  mldiiolnt  of  each  bit  time  (see  figure  2). 

4. 3. 3. 3 Transmission  bit  rate.  The  transmission  bit  rate  on  the  bus  shall  be 
1.0  megabit  per  second  with  a combined  accuracy  and  long-term  stability  of  J 
0.1  percent  (i.e.,  t 1000  Hertz  (Hz)).  The  short-tenn  stability  (i.e., 
stability  over  1.0  second  Interval)  shall  be  at  least  0.01  percent  (l.e.,  * 100 
Hz) . 

l4.3.3.*4  Word  size.  Ihe  word  size  shall  be  16  bits  plus  the  sync  waveform  and 
the  parity  bit  for  a total  of  20  bits  times  as  shown  on  figure  3. 

14.3.3.5  Word  formats.  The  word  formats  shall  be  as  shown  on  figure  3 for  the 
command,  data,  and  status  wor-ds. 
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M.3<3>5-1  t^QUMllj  W?rd  - A ctwiffland  wi>r«l  atiall  be  comprised  of  a sync  Maveform, 
remote  terminal  address  field , traiianl  t/recelve  (T/H)  bit,  subaddress/mode 
field,  word  count/mode  code  field,  and  a parity  IF)  bit  (see  figure  3)* 

4.3>3<5-1-1  Svnc . The  command  sync  waveform  shall  be  an  Invalid  Manchester 
waveform  as  shown  on  figure  <1.  The  width  shall  be  three  bit  times,  with  the 
sync  waveform  being  positive  for  the  first  one  and  one-tial(  bit  times,  and  then 
negative  for  the  following  one  and  one-talf  bit  times.  If  the  next  bit 
following  the  sync  waveform  Is  a logic  zero,  then  the  last  half  of  the  sync 
waveform  will  have  an  apparent  width  of  two  clock  periods  due  to  the  Manchester 
encodliig . 

••.3. 3. 5. 1.2  Remote  terminal  address.  The  next  five  bits  following  the  syno 
shall  be  the  RT  address.  Each  RT  shall  be  assigned  a unique  address.  Decimal 
address  31  (11111)  shall  not  be  assigned  as  a unique  address.  In  addition  to 
its  unique  address,  a RT  shall  be  assigned  decimal  address  31  (11111)  as  the 
common  address,  if  the  broadcast  option  is  used. 

^.3. 3. 5. 1.3  Transmit /receive.  The  next  bit  foll.iwlng  the  remote  terminal 
address  shall  be  the  T/R  bit,  which  shall  Indicate  the  action  required  of  the 
RT.  k logic  zero  shall  indicate  the  RT  is  to  receive,  and  a logic  one  shall 
Indicate  the  RT  is  to  transmit. 


R . 3 .3  .^  . 1 .*1  Subaddr ass/mode . The  next  five  bits  following  the  R/T  bit  shall 
be  utilized  to  indicate  an  RT  subaddress  or  use  of  a<xle  control,  as  Is  dictated 
by  the  individual  terminal  requirements.  The  subaddress/mode  values  of  00000 


and  11111  are  reserved  for  special  purposes,  as  specified  in  *1.3.3.5.1.71  and 
shall  not  be  utilized  for  any  other  function. 


I. 3. 3. 5.1. 5 Data  word  count/mode  code.  The  next  five  bits  following  the 
subaddress/mode  field  shall  be  the  quantity  of  data  words  to  be  either  sent  out 
or  received  by  the  RT  or  the  optli^nal  mode  code  as  specified  in  11.3.3.5.1.7.  A 
maximum  of  32  data  words  may  be  transmitted  or  received  in  any  one  message 
block.  All  1's  shall  Indicate  a decimal  count  of  31 > and  all  O's  shall 
indicate  a decimal  count  of  32. 

II. 3.3.5.1.6  Parity . The  last  bit  In  the  word  shall  be  used  for  parity  over 
the  preceding  16  bits.  Odd  parity  shall  be  utilized. 

A.  3. 3. 5. 1.7  Optional  mode  control.  For  RT's  exercising  this  option  a 
subaddress/mode  code  of  00000  or  11111  shall  Imply  that  the  contents  of  the 
data  word  oount/mode  code  field  are  to  be  decoded  as  a five  bit  mode  command. 
The  mode  code  shall  only  bn  used  to  communicate  with  the  multiplex  bus  related 
hardware,  and  to  assist  In  the  management  of  Information  flow,  and  not  to 
extract  data  from  or  feed  data  to  a functional  subsystem.  Codes  00000  through 
01111  shall  only  be  used  for  mode  . .»des  which  do  not  require  transfer  of  a data 
word.  For  these  codes,  the  T/R  bit  shall  be  set  tv>  1.  Codes  10000  through 
11111  shall  only  be  used  for  mode  codes  which  require  transfer  of  a single  data 
word.  For  these  mode  codes,  the  T/R  Mt  shall  Indicate  the  direction  of  data 
word  flow  as  specified  In  M . 3 . 3 .*> . 1 . 3 . No  multiple  data  word  transfer  shall  be 
implemented  with  any  mode  code.  The  mode  codes  are  reserved  for  the  specific 
functions  as  specified  In  table  I and  shall  not  be  used  for  any  other  purpose. 
If  the  designer  chooses  tv>  implement  any  of  these  functions,  the  specific 
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codes,  T/'R  bit  assignments,  ano  use  of  a data  woici,  shall  be  used  as  Indicated. 
The  use  of  the  broadcast  command  optsoti  shall  only  be  applied  to  particular 
mode  codes  as  specified  in  table  [. 

*1 .3 .3 .8 . 1 .7 . 1 Dynamic  bus  control.  The  controller  shall  issue  a transmit 
caomand  to  an  RT  capable  of  perfiirmlng  the  bus  (nintrol  function.  This  RT  shall 
respond  with  a status  word  as  sp<fcified  in  4.  i.  3.5.3.  Control  of  the  data  bus 
passes  from  the  offering  bus  controller  tii  the  accepting  RT  upon  completion  of 
the  transmission  of  the  status  word  by  the  HT . If  the  RT  rejects  control  of 
the  data  bus,  the  offering  bus  controller  retains  control  of  the  data  bus. 

4 . 3.3 .5 . 1 .7  .2  Synchronize  (without  data  word).  This  command  shall  cause  the 
RT  to  synchronize  (e.g.,  to  reset  the  internal  timer,  to  start  a sequence, 
etc.).  The  RT  shall  transmit  the  status  w<)rd  as  specified  in  4.3.3.5.3. 

4. 3. 3.5. 1 .7.3  Transmit  status  word.  This  command  shall  cause  the  RT  to 
transmit  the  status  word  associated  with  the  last  valid  command  word  preceding 
this  command.  This  mode  command  shall  n>)t  alter  the  state  of  the  status  word. 

4 . 3 -3 .5 . 1 .7 .4  Initiate  soif  test.  This  command  shall  be  used  to  Initiate  self 
test  within  the  RT.  The  RT  shall  transmit  the  status  word  as  specified  in 

4. 3. 3.5. 3. 

4 . 3 • 3 .5 . 1 .7  .5  Transmitter  shutdown.  This  0i)mm3nd  (to  only  be  used  with  dual 
redundant  bus  systems)  shall  cause  the  hT  to  disable  the  transmitter  associated 
with  the  redundant  bus.  The  RT  shall  not  comply  with  a command  to  shut  down  a 
transmitter  on  the  bus  from  which  this  c.mimand  Is  received.  In  ail  cases,  the 
RT  shall  respond  with  a status  word  as  specifii-d  In  4. 3. 3.5.3  after  this 
command. 

4 . 3 . 3 .5 . 1 .7 .6  Override  transmitter  shutdown.  This  command  (to  only  be  used 
with  dual  redundant  bus  system)  shall  cause  the  RT  to  enable  a transmitter 
which  was  previously  disabled.  The  RT  shall  not  comply  with  a command  to 
enable  a transmitter  on  the  bus  from  which  this  command  is  received.  In  all 
cases,  the  RT  shall  respond  with  a status  word  as  specified  in  4. 3. 3. 5. 3 after 
this  command. 

4 .3 .3.5 .1 .7  .7  Inhibit  terminal  flag  (I/F)  bit.  This  command  shall  cause  the 
RT  to  set  the  T/F  bit  in  the  status  word  specified  in  4. 3. 3.5. 3 to  logic  zero 
until  otherwise  comnanded.  The  HT  shall  transmit  the  status  word  as  specified 
In  4. 3. 3. 5. 3. 


4 . 3 .3 .5 . 1 .7  .8  Qveri'ide  inhibit  T/F  bit.  This  command  shall  cause  the  RT  to 
override  the  Inhibit  T/F  bit  specified  In  4 . 3 . 3 .5 . 1 .7  .7 . The  RT  shall  transmit 
the  status  word  as  specified  in  4.^.3. 5. 3. 

4. 3. 3. 5.1 .7.9  Reset  remote  terminal.  This  c >mmand  shall  be  used  to  reset  the 
RT  to  a power  up  Initialized  stale.  The  RT  shall  first  transmit  its  status 
word,  and  than  reset. 

4.3.3.5.1.7.10  Reserved  mode  codes  (OIOQI  to  011  11).  These  mode  codes  are 
reserved  for  future  use  and  shall  not  be  used. 
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TABLK  1.  A33\Rned  node  codea 


rtfldt  Code 

Function 

Assoc lated 

Data  Nord 

00000 

Dynamic  bus  Control 

No 

00001 

Synchronize 

No 

00010 

Transmit  Status  Word 

No 

000  n 

Initiate  Self  Test 

No 

00100 

Transmitter  Shutdown 

No 

00101 

Override  Transmitter  Shutdown 

No 

00110 

Inhibit  Terminal  Flag  Bit 

No 

00111 

Override  Inhibit  Terminal  Hag 

bit 

No 

01000 

He  set  Remote  Terminal 

No 

01001 

Reserved 

No 

1 

01111 

Reserved 

No 

1 

10000 

Transmit  Vector  Word 

Yes 

0 

10001 

Synchronize 

Yes 

1 

10010 

Transmit  Last  Command 

Yes 

1 

1001 1 

Transmit  BIT  Word 

Yes 

0 

10100 

Selected  Transmitter  Shutdown 

Yes 

0 

10101 

Override  Selected  Iransmltter 
Shutdown 

Yes 

1 or 

0 

lullO 

1 

Reserved 

1 

Yes 

1 

1 or 

0 

1 

11111 

1 

Reserved 

Yes 

NOTE:  To  be  determined  ITBP) 


Broadcast 
Co—aiid  Allowed 

No 

Tea 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

TBD 

1 

TBD 

No 

Yes 

No 

No 

Yes 

Yes 

TBD 

i 

TBD 
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1|.  3- 3- 6 . 1 . 7 . 1 1 Transmit  vector  word.  Tliis  c<.<mmaiKl  shall  cause  the  HT  to 
transmit  a status  word  as  spectt'leO  in  3 anh  a data  word  containing 

service  request  infonnation . 

*<•  3.  3- 5.  1 ■ 7 ■ IP  Synchronize  (with  ijata  word).  Iho  hi  shall  receive  a command 
word  followed  by  a data  w "d  as  spedfieil  in  'i.j-.l-h.P.  Ihe  data  word  shall 
contain  synchronization  Information  Jor  the  HI.  Alter  receiving  the  command 
and  data  word,  the  HI  shall  transmit  the  status  word  as  specified  in  U.3-3-3.3' 

“l.  3- 3- 5.  1 . 7.  13  Transmit  last  command  word.  This  comnnuid  shall  cause  the  HT  to 
transmit  its  status  word  as  specilied  in  *4.3*3-‘j.3  followed  by  a single  data 
word  which  contains  bits  11-I9  of  the  last  command  word,  excluding  a transmit 
last  command  word  mode  code  received  by  the  HT.  This  mixle  command  shall  not 
alter  the  state  of  the  HT's  status  wol^l. 

4.  3.  3- 5.  1 . 7 • 1 Transmit  built- in-test  (blT)  word.  This  command  shall  cause 
the  HT  to  transmit  Its  status  ivord  as  sfiecifled  In  4.3-3-b.3  followed  by  a 
single  data  word  containing  the  HT  BIT  data.  This  function  is  intended  to 
supplement  the  available  bits  In  the  status  word  when  the  HT  hardware  is 
sufficiently  complex  to  warrant  Its  use.  The  daia  word,  containing  the  RT  BIT 
data,  shall  not  be  altered  by  the  reception  of  a transmit  last  command  or  a 
transmit  status  word  mode  code.  This  function  shall  not  be  used  to  convey  BIT 
data  from  the  associated  subsystem!  s) . 

* 

4. 3-  3- 5. 1 . 7.  15  Selected  transmitter  shutdown.  This  command  shall  cause  the  RT 
to  disable  the  transmitter  associated  with  a specified  redundant  data  bus.  The 
command  is  designed  for  use  with  systems  employing  more  tlian  two  redundant 
buses.  The  transmitter  that  Is  to  be  disabled  shall  be  Identified  in  the  data 
word  lollowing  the  command  word  in  the  format  as  specified  in  M.3.3-5.2.  The 
RT  shall  not  comply  with  a command  to  shut  down  a transmitter  on  the  bus  from 
which  this  command  is  received.  In  all  cases,  the  HT  shall  respond  with  a 
stetus  word  as  specified  in  4. 3. 3.5.3. 

• 3.3.5.1.7.16  override  selected  transmitter  shutdown-  This  command  shall 
'.ause  the  HT  to  enable  a transmitter  which  was  previously  disabled.  The 
crxtmand  Is  designed  for  use  with  systems  employing  more  than  two  redundant 
buses.  The  transmitter  that  is  to  be  enabled  shall  be  identified  in  the  data 
word  following  the  cixnroand  word  in  the  tormat  as  specified  in  4.3.3-5.P.  The 
HT  shall  not  comply  with  a command  to  enable  a transmitter  on  the  bus  from 
which  this  command  is  received.  In  all  oa.ses,  the  RT  shall  respond  with  a 
status  word  as  specified  in  4. 3. 3.5, 3. 

4.3.3- 5.1.7.17  Heaerved  mode  codes  ilOllQ  to  VUlli-  These  mode  codes  are 
reserved  for  future  use  and  shall  not  be  used. 

4. 3. 3.5.2  Data  word.  K data  word  shall  be  compri.sed  of  a sync  waveform,  data 
bits,  and  a parity  bit  (see  flgui-e  3). 

4. 3- 3-5. 2.1  Svnc . The  data  sync  wavofotm  shall  be  .ni  invalid  Manchester 
waveform  as  shown  on  figure  5.  The  width  shall  be  three  bit  times,  with  the 
waveform  being  negative  for  the  first  one  and  one-lialf  bit  times,  and  then 
positive  for  the  following  one  and  one-half  hit  times.  Note  that  if  the  bits 
preceding  and  lollowing  the  sync  are  logic  ones,  llien  the  apparent  width  of  the 
sync  waveform  will  be  increaseii  to  four  bit  times. 
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*•.  3- H- 5.  t . iittkfl-  s>xte«'n  bits  followuiji  1(k>  syiio  shall  be  utlll2ecl  for 

(lata  transnt  salon  as  •>  p»*'' 1 1 i evl  in  •l.'l.i'. 

*1  • 3*  3- S.  t*.  3 LaTLIX-  The  last  bit  shall  bi'  utlltjeil  lor  ivirlty  as  specified  In 
<*.3. 3 b.  l.b. 

1•3•3•b.3  2L4Lua  MMl'il  A status  word  shall  bo  ooaprlsed  of  a ayno  wavefora, 

RT  address,  aessage  enor  Dll,  Inst  rumonl  at  ion  bit,  service  request  bit,  thraa 
reserved  bits,  broadcast  oonwwtnd  received  bit.  busy  bit,  subsystea  flag  bit, 
dynaalc  bus  control  acceptance  bit,  terminal  flag  bit,  and  a parity  bit.  For 
optional  broadcast  operation,  transmission  of  the  status  word  shall  be 
suppressed  as  specified  In  >4.  3.  3 .6.7. 

1.3.3. 5. 3.1  Svnc.  The  status  sync  waveform  shall  be  as  specified  in 

1.3. 3. 5. 1.1. 

1.3.3. 5. 3. 2 £I_gililXia;ia . The  next  five  bits  following  the  syno  shell  oonteln 
the  eddress  of  the  RT  which  is  transmitting  the  status  word  as  defined  In 

1.3. 3. 5. 1.2. 

1.3. 3. 5. 3.3  Message  error  bit . The  status  word  bit  at  bit  tlae  nine  (see 
figure  3)  shell  be  ullllicd  to  Indicate  that  one  or  more  of  the  data  words 
associated  with  the  preceding  receive  command  word  from  the  bus  controller  has 
felled  to  pass  the  RT*s  validity  tests  as  specified  In  M.M.I.I.  This  bit  shall 
also  be  set  under  the  conditions  specified  in  1.4. 1.2,  4. 4. 3.1  end  1.1. 3. 6.  A 
logic  one  shell  Indicate  the  presence  of  a message  error,  and  • loglo  xero 
shall  show  its  absence.  All  RT's  shall  implement  the  message  error  bit. 

1.3. 3. 5. 3.1  Instrumentation  bit.  The  status  word  at  bit  time  ten  (sea  figure 
3)  shall  be  reserved  for  the  Instrumentation  bit  and  shall  always  be  a loglo 
xero.  This  bit  Is  Intended  to  be  used  in  conjunction  with  a loglo  one  In  bit 
time  ten  of  the  command  word  to  distinguish  between  a command  word  and  a status 
word.  The  use  of  the  Instrumentation  bit  Is  optional. 

1.3. 3.5. 3. 5 Service  request  bit.  The  status  word  bit  at  bit  time  eleven  (sea 
figure  3)  shall  be  reserved  for  the  service  request  bit.  The  use  of  this  bit 
is  optional.  This  bit  when  used,  shall  Indicate  the  need  for  the  bus 
oontroller  to  take  specific  predefined  actions  relative  to  either  the  RT  or 
associated  subsystea.  Multiple  subsystems,  Interfaced  to  a single  RT,  which 
individually  require  a service  request  signal  shall  logically  OR  their 
individual  signals  Into  the  single  status  word  bit.  In  the  event  this  logical 
OR  Is  performed,  then  the  designer  most  make  provisions  in  a separate  data  word 
to  identify  the  specific  requesting  subsystem.  The  service  request  bit  is 
intended  to  be  used  only  to  trigger  data  transfei'  operations  which  take  place 
on  an  exception  rather  than  periodic  basis.  A l.>glo  one  shall  Indicate  the 
presence  of  a service  request,  and  a logic  zero  Its  absence.  If  this  function 
is  not  implemented,  the  bit  shall  be  set  to  zero. 


1.3. 3. 5. 3. 6 Reserved  status  tiXLa.  The  status  word  bits  at  bit  times  twelve  il 

through  fourteen  are  reserved  for  future  use  and  shall  not  be  used.  These  bits 
shall  be  set  to  a logic  zero. 
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H . 1 . ) .5 . 1 hrQAili.ii.3L  CuBUftilKl- 1 ei:viVA:U  liXL-  'Kie  status  word  at  bit  lime 
fifteen  shall  be  set  to  a logvo  one  to  indlrate  that  the  preredlng  valid 
comaiand  word  was  a br>)adoast  oommand  and  a zero  shall  show  It  was  not  a 

broadcast  command.  If  the  broadoast  conimond  .)ptlon  Is  nc5t  used,  this  bit  shall 
be  set  to  a logic  zero. 

fiuait  bll.  The  status  woru  tat  at  bit  time  sixteen  (see  figuhe  3) 
shall  be  reserved  for  the  busy  bit.  The  use  .if  this  bit  Is  optional.  This 
bit,  when  used,  shall  Indicate  tlial  tin-  HT  subsystem  Is  unable  to  move  data 
to  or  from  the  subsystem  In  c.itnpliance  with  tie*  t)us  controller's  ci^mmand.  A 
logic  one  shall  indicate  the  preseru'e  . f a busy  condition,  and  a logic  zero  its 
absence.  In  the  event  the  busy  bit  Is  set  in  response  to  a transmit  command, 
then  the  RT  shall  transmit  Its  status  wjrd  .inly.  If  this  function  is  not 
implemented,  the  bit  shall  be  set  i.i  l.igi<'  z-t.). 

‘•.3.3.5.3.9  Subsystem  flan  bit.  The  status  wird  bit  at  bit  time  seventeen 
(see  figure  3)  shall  be  reserved  for  the  subsystem  flag  bit.  The  use  of  this 
bit  is  optional.  This  bit,  when  used,  stiall  flag  a subsystem  fault  condition, 
and  alert  the  bus  controller  to  p.nentially  Invalid  data.  Multiple  subsystems, 
interfaced  to  a single  RT,  which  individually  require  a subsystem  flag  bit 
signal  shall  logically  OR  their  individual  signals  Into  the  single  status  word 
bit.  In  the  event  this  logical  OR  is  perf.-rmed,  then  the  designer  must  make 
provisions  in  a separate  data  word  to  identify  the  specific  reporting 
subsystem.  A logic  one  shall  Indicate  the  presence  of  the  flag,  and  a logic 
zero  its  absence.  If  not  used,  this  bit  shall  be  set  to  logic  zero, 

**.3.3.5.3.10  bus  I'pntrol  aooeptance  bit.  The  status  word  bit  at  bit 

time  eighteen  (see  figure  3)  shall  be  reserved  for  the  acceptance  of  dynamic 
bus  control.  This  bit  shall  be  used  If  the  RT  implements  the  optional  dynamic 
bus  control  function.  This  bit,  when  used,  shall  Indicate  acceptance  or 
rejection  of  a dynamic  bus  control  offer  as  specified  in  *1 . 3 . 3.5 . 1 .7 . 1 . A 
logic  one  shall  indicate  acceptance  of  control,  and  a logic  zero  shall  indicate 
rejection  of  control.  If  this  function  Is  not  used,  this  bit  shall  be  set  to 
logic  zero. 

*•  .3 .3 .5 .3 . 1 1 Tei^minal  flag  bit.  Trie  status  word  bit  at  bit  time  nineteen  (see 
figure  3)  shall  be  reserved  for  the  terminal  flag  function.  The  use  of  this 
bit  is  optional.  This  bit,  when  used,  shall  flag  a RT  fault  condition.  A 
logic  one  shall  indicate  the  presence  .if  the  flag,  and  a logic  zero,  its 
absence.  If  not  used,  this  bit  sh.ill  be  set  to  logic  zero. 

**  .3.3.5 .3.12  Rarity  bit.  The  least  significant  bit  In  the  status  word  shall 
bo  utilized  for  parity  as  specified  m . 3 . 3 .S  . 1 , b . 

**.3.3.5.**  Status  word  reset.  The  status  wm  d bit,  with  the  exception  of  the 
address,  shall  be  set  to  l.iglc  zero  after  a valid  command  word  is  received  by 
the  RT  with  the  exceptiiin  as  spocifi.’d  In  R . 3 . 3 .5 . 1 . If  the  conditions  which 
caused  bits  in  the  status  word  l.,  be  sol  (eg.,  terminal  flag)  continue  after 
the  bits  are  reset  to  logic  zer..>,  tti-n  th.-  affe.'led  status  word  bit  shall  be 
again  set,  and  then  transmitted  >'n  tto-  bus  as  required. 

**.3.3.6  flessage  formats.  The  messages  transmitted  on  the  data  bus  shall  be  in 
accordance  with  the  foriaats  on  figure  b and  figure  ^ . The  maximum  and  minimum 
response  times  shall  be  as  stated  in  v . 3 • 3 • and  *t.3.3.fl.  No  massage  forauts, 
other  than  those  defined  herein,  shall  be  used  on  the  bus. 
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‘<.3-3-o.1  bus  controller  lo  remote  termindl  tranal'ers.  The  bus  controller 
shall  Issue  a receive  cccunano  followed  by  the  specll'lec)  number  of  data  words. 

The  RT  shall  , after  niessaKe  validation,  transmit  a status  word  back  to  the 

controller.  The  command  and  data  words  shall  be  transmitted  In  a contiguous 
fashion  with  no  Interword  gaps. 

‘••B.j.b.P  tieiBOte  terminal  to  bus  controller  translers.  Tt\e  bus  controller 
shall  issue  a tran.sinlt  C(.inunand  to  the  HT.  The  HT  shall,  after  command  word 

validation,  transiiill  a status  wf>rd  bacK  to  ttie  bus  controller,  followed  by  the 

specified  nunber  of  data  words.  The  status  and  data  words  shall  be  transmitted 
In  a contiguous  fa.dilon  with  no  interword  gaps. 

*••3. 3. 6. 3 Hemote  terminal  to  remote  terminal  transfers.  The  bus  controller 
shall  l.ssue  a receive  command  to  RT  A followed  contiguously  by  a transmit 

to  RT  B.  RT  B shall,  after  command  validation,  transmit  a status  word 
followed  by  the  specified  number  of  data  words.  The  status  and  data  words 
shall  be  transmitted  In  a contiguous  fashion  with  no  gap.  At  the  conclusion  of 
the  data  tran.smisslon  by  RT  B,  RT  A shall  transmit  a status  word  within  the 
specified  time  period. 


4.3.3.6.11  y^tpaand  without  data  word.  The  bus  controller  shall  Issue  a 

transmit  command  to  the  RT  using  a mode  code  specified  In  table  I.  The  RT 
shall,  after  command  word  validation,  trcinsmlt  a status  word. 

‘1-3-3-6.5  Mode  command  with  data  word  (transmit).  The  Bus  controller  shall 
lasue  a transmit  command  to  the  RT  using  a mode  code  specified  In  table  I.  The 
RT  shall,  after  command  word  validation,  transmit  a status  word  followed  by  one 
data  word.  The  status  word  and  data  word  shall  be  transmitted  In  a contiguous 
fashion  with  no  gap. 

4. 3. 3.6.6  Hode  coflunand  with  data  word  (receive).  The  bus  controller  shall 
Issue  a receive  command  to  the  RT  using  a mode  code  specified  In  table  1, 
followed  by  one  data  word.  The  command  word  and  data  word  shall  be  trananitted 
in  a contiguous  fashion  with  no  gap.  The  RT  shall,  after  command  and  data  word 
validation,  transmit  a status  word  back  to  the  controller. 

4.  3.  3.6.7  Optional  broadca.st.  cnmmanri . See  10.6  for  additional  Information  on 
the  use  of  the  broadcast  command. 

4. 3. 3. 6. 7.1  bus  controller  to  remote  terminal(s)  transfer  (broadcast)  The 
bus  controller  shall  Issue  a receive  command  word  with  11111  in  the  BT  address 
field  followed  by  the  specified  nunber  of  data  words.  The  command  word  and 
data  words  shall  be  transmitted  in  a contiguous  fashion  with  no  gap.  The  RTia) 
with  the  broadcast  option  shall  after  message  validation,  set  the  broadcast 
command  received  bit  In  the  status  word  as  specified  In  4.3.3>5.3>7  and  shall 
not  transmit  the  status  word. 
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4. 3. 3. 6. 7. 2 Raaota  termlnai  to  ramote  tenninalCa)  transfera  tbroadcaat).  The 
bua  controller  ehall  Issue  a receive  command  word  with  11111  In  the  RT  address 
field  followed  by  a transmit  command  to  HI'  A using  the  NT's  address.  RT  A 
shall,  after  coaunand  word  validation,  transmit  a status  word  followed  by  the 
speolfled  number  of  data  words.  The  status  and  data  words  shall  be  transmitted 
In  a contiguous  fashion  with  no  gap.  Ttie  RT(s)  with  the  broadcast  option, 
excluding  HI  A,  shall  after  message  validation,  set  the  broadcast  received  bit 
In  the  status  word  as  specified  In  4. 3. 3.5. 3-7  and  shall  not  transmit  the 
status  word. 

4.  3.  3. 6. 7. 3 yffmamnd  without  data  word  (broadcast).  The  bus  controller 

shall  Issue  a transmit  command  word  with  11111  In  the  RT  address  field,  and  a 
mode  code  specified  in  table  1.  The  RT(s)  with  the  broadcast  option  shall 
after  coomand  word  validation,  set  the  brciadcast  received  bit  in  the  status 
word  as  specified  In  4. 3. 3.5. 3.7  and  shall  not  transmit  the  status  word. 

4. 3. 3.6. 7. 4 Mode  command  with  data  word  (broadcast).  The  bus  controller  shall 
Issue  a receive  command  word  with  11111  In  the  HT  address  field  and  a mode  code 
specified  In  table  1,  followed  by  one  data  word.  The  command  word  and  data 
word  shall  be  transmitted  in  a contiguous  fashion  with  no  gap.  The  RTCs)  with 
the  broadcast  option  shall  after  message  validation,  set  the  broadcast  received 
bit  In  the  status  word  as  specified  in  4. 3. 3. 5. 3. 7 and  shall  not  transmit  the 
status  word. 

4. 3. 3. 7 Intermessaae  gap.  The  bus  controller  shall  provide  a mlnlmun  gap  time 
of  4.0  microseconds  (ais)  between  messages  as  shown  on  (igure  b and  figure  7- 
This  time  period,  shown  as  T on  figure  8,  Is  measured  at  point  A of  the  bus 
controller  as  shown  on  figure  9 or  figure  10.  The  time  is  measured  from  the 
mld-blt  zero  crossing  of  the  last  bit  of  the  preceding  message  to  mid-zero 
crossing  of  the  next  command  word  sync. 

4. 3.3. 8 Response  time.  The  HT  shall  respt^nd  , In  accordance  with  4. 3.  3.6,  to  a 
valid  command  word  within  the  time  period  of  4.0  to  12.0  ns.  This  time  period, 
shown  as  T on  figure  8,  is  measured  at  point  A of  the  HT  as  shown  on  figure  9 
or  figure  10.  The  time  Is  measured  frtim  the  mid  bit  zero  crossing  of  the  last 
word  as  specified  in  4. 3.  3.6  and  as  shown  on  figure  6 and  figure  7 to  the 
mid-zero  crossing  of  the  status  word  sync. 

4. 3. 3.9  Minimum  no-resDonse  timc-out.  Ihe  mlnimin  time  t1»at  a terminal  shall 
wait  before  considering  that  a response  as  specified  In  4. 3. 3.8  not 
occurred  shall  be  14.0  ns.  The  time  is  measured  Irom  the  mld-blt  zero  crossing 
of  the  last  bit  of  the  last  word  to  the  mid-zero  crossing  of  the  expected 
status  woixl  sync  at  ^>olnt  A of  the  terminal  as  shown  on  figure  9 or  figure  10. 


4.4 


4.4.1  Common  operation.  Terminals  shall  h.ave  cixnmon  operating  caF>ab  11  itles  as 
specified  in  the  following  paragraphs. 


i 
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FIGURE  10.  Data  bus  Interface  using  direct  coupling . 
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4.<».1.l  Word  validation.  The  terminal  shall  Insure  that  each  word  conforms  to 
the  following  mlnlmun  criteria: 

a.  The  word  begins  with  a valid  sync  field. 

b.  The  bits  are  in  a valid  Manchester  II  code. 

c.  The  information  field  has  16  bits  plus  parity. 

d.  The  word  parity  is  odd. 

When  a word  falls  to  conform  to  the  preceding  criteria,  the  word  shall  be 
considered  invalid. 

4.4. 1.2  Transmission  continuity.  The  terminal  shall  verify  that  the  message 
is  contiguous  as  defined  in  4.  3.  3.6.  Improperly  timed  data  syncs  shall  be 
considered  a message  error. 

4.4. 1.3  Terminal  fail-safe.  The  terminal  shall,  contain  a hardware  implemented 
time-out  to  preclude  a signal  transmission  of  greater  than  800.0  its.  This 
hardware  shall  not  preclude  a correct  transmission  in  response  to  a command. 
Reset  of  this  time-out  function  shall  be  performed  by  the  reception  of  a valid 
command  on  the  bus  on  which  the  time-out  has  occurred. 


4.4.2  Bus  controller  operation.  A terminal  operating  as  a bus  controller 
shall  be  responsible  for  sending  data  bus  commands,  participating  in  data 
transfers,  receiving  status  responses,  and  monitoring  system  status  as  defined 
in  this  standard,  the  bus  controller  function  may  be  embodied  as  either  a 
stand-alone  tens  Inal , whose  sole  function  Is  to  control  the  data  bua( s)  , or 
contained  within  a subsystem.  Only  one  terminal  shall  be  in  active  control  of 
a data  bus  at  any  one  time. 


4.4.3.  1 Oberatilon . A remote  terminal  (RT)  shall  operate  in  response  to  valid 
commands  recelvjed  from  the  bus  controller.  The  RT  shall  accept  a command  word 
as  valid  when  the  command  word  meets  the  criteria  of  4.4. 1.1,  and  the  command 
word  contains  i tennlnal  address  which  matches  the  RT  address  or  an  address  of 
11111,  if  the  ftT  has  the  broadcast  option 


4. 4. 3.2  Superseding  valid  commands.  The  HT  shall  be  capable  of  receiving  a 
command  word  on  the  data  bus  after  tne  minimuD  intermessage  gap  time  as 
specified  in  4:.  3- 3.7  has  been  exceeded,  when  the  RT  Is  not  in  the  time  period  T 
as  specified  in  4. 3. 3-8  prior  to  the  transmission  of  a status  word,  and  when  it 
is  not  transmitting  on  that  data  bus.  A second  valid  command  word  sent  to  an 
RT  shall  take  precedence  over  the  previous  command.  The  RT  shall  respond  to 
the  second  valid  command  as  specified  in  4.  3.  3.8. 


4.4. 3*3  Invalid  commands.  A remote  terminal  shall  not  respond  to  a coousand 
word  which  falls  to  meet  the  criteria  specilieil  in  4. 4.  3.1. 


4. 4. 3. 4  Illegal  command.  An  illegal  command  is  a valid  command  as  specified 
in  4.4.3.  1,  where  the  bits  In  the  subaddresa/mod«  Iield,  data  word  count/mode 
code  field,  and  the  T/fl  bit  indicate  a mode  command,  subaddress,  or  word  count 
that  has  not  been  implemented  in  the  HT . II  is  the  responsibility  of  the  bus 
controller  to  assure  that  no  illegal  cixnmands  are  sent  out.  The  RT  designer 
has  the  option  of  monitoring  (or  illegal  ccxnmands.  If  an  HT  that  is  designed 
with  this  option  detects  an  illegal  command  and  the  proper  niinber  of  contiguous 
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valid  data  WDitla  as  siv'o  1 1 led  by  the  lllejtal  cmnm.uid  wtn'd , It  shall  resi^ond 
with  a status  word  only,  setting  the  message  erix)r  bit,  and  ivit  use  the 
Inf'onnatlon  reoeiveil . 

*1.4.  j.S  Valid  data  recoL'tlon.  The  remote  terminal  shall  res(iotKl  with  a status 
word  when  a valid  oivnroaiKl  wi\l  and  the  pivper  minbor  of  oontigu^>us  valid  data 
words  are  received,  or  a single  valid  wi'txl  associated  with  a raixle  code  is 
received.  Kach  data  *a>r\l  shall  meet  the  criteria  spool  fieil  In  4.4.  1.1. 

4.4. 3. (>  Invalid  data  reception.  Any  data  word(s)  associated  with  a valid 
receive  commarKl  that  does  iK^t  meet  the  criteria  spe<?it'lcHl  In  4.4.  l.l  and 

4.4.  1.2  or  an  error  In  the  data  woixl  coiuit  shall  cause  the  remote  terminal  to 
sot  the  message  error  bit  In  the  status  word  to  a logic  one  and  suppress  the 
transmission  of  the  status  word.  If  a ries3.age  error  tias  occurred,  then  the 
wtire  message  shall  be  considered  invalid. 

4.4.4  Bus  monitor  operation.  A terminal  ofierating  as  a bus  monitor  stiall 
receive  bus  traffic  and  extract  selected  in  format  ion  . While  operating  as  a bus 
monitor,  the  terminal  shall  not  respotul  to  any  mes.sage  except  one  containing 
Its  own  unique  address  If  one  is  asstgneil.  All  Information  obtained  while 
acting  as  a bus  monitor  shall  be  strictly  used  for  off-line  applications  (e.g., 
flight  test  recording,  maintenance  recording  or  mission  analysis)  or  to  provide 
the  back-up  bus  controller  sufficient  information  to  take  over  as  the  bus 
controller . 

4 . 5 Hardware  characteristics . 


4.5. 1 


4.5.  1.1  Cable . The  cable  used  for  the  main  bus  and  all  stubs  shall  be  a two 
conductor,  twisted,  shielded.  Jacketed  cable.  The  wlre-to-wlre  distributed 
capacitance  shall  not  exceed  jO.O  picofarads  per  foot.  The  cables  shall  be 
formed  with  not  less  than  four  twists  per  foot  where  a twist  Is  defined  as  a J 

360  degree  rotation  of  the  wire  pairs;  and,  the  cable  shield  shall  provide  a i' 

mlnlauB  of  75.0  percent  coverage. 

4. 5. 1.2  Charaetarlstic  impedance.  The  nominal  characteristic  iapedanoe  of  the 

oabla  (Zo^  shall  be  within  the  range  of  TO.O  ohms  to  85.0  ohms  at  a sinusoidal  ’ 

fraquency  of  1.0  megahertz  (HHz). 

4.5. 1.J  Cable  attenuation.  At  the  frequency  of  4.S.1.2,  the  cable  power  loss 
shall  not  exceed  1.5  decibels  (dB)/100  feet  (ft). 

4.5.  1.4  Cable  termination.  The  two  ends  of  the  cable  shall  be  terminated  with 

a resistance,  equal  to  the  sele<ned  cable  n>mlnal  characteristic  impedance  ( Zq)  ^ 

t 2.0  percent.  f; 

4.5.  1.5  Cable  stub  reouirements . The  cable  shall  be  coupled  to  the  terminal  ,i  ' 

as  shown  on  figure  9 or  (Igiu'e  U).  The  use  of  long  stubs  Is  discouraged,  and 
the  length  of  a stub  should  be  minimized.  However,  If  Installation 

requirements  dictate,  stub  ler^ths  exceeding  those  lengths  specified  In  I 

4.5.  1.5.  1 and  4.5.  1.5.2  are  permissible.  j 


•>1 

as2 


MIL-STD-1553fa 
1 September  1978 


^.5.  1.5.1  Tranaformer  couoled  stubs.  Ihe  length  o1  a transformer  coupled  stub 
should  not  exceed  20  feet.  If  a transformer  coupled  stub  la  used,  then  the 
following  shall  apply. 

4.5. 1.5. 1.1  CoupltnR  transformer.  A (coupling  transformer,  as  shown  on  figure 
9,  shall  be  required.  This  transformer  shall  have  a turns  ratio  of  1:1,41  i 

3.0  percent,  with  the  higlier  turns  on  t.hf>  isolation  resistor  side  of  the  stub. 

4. 5. 1.5. 1.1.1  Transformer  input  Impedance.  The  open  circuit  impedance  as  seen 
at  point  B on  figure  11  shall  be  greater  than  3000  ohms  over  the  frequency 
range  of  75.0  kilohertz  (kHz)  to  1.0  megahertz  (MHz),  when  measured  with  a 1.0  V 
root'-aean-square  (RMS)  sin  wave. 

4 .5 . 1 .5 . 1 . 1 .2  Transformer  waveform  integrity.  The  droop  of  the  transformer 
using  the  test  configuration  shown  on  figure  11  at  point  B,  shall  not  exceed 

20.0  percent.  Overshoot  and  ringing  as  measured  at  point  B shall  be  less  that 
i 1 .0  V peak.  For  this  test,  H shall  equal  360.0  ohms  1 5.0  percent  and  the 
input  A of  figure  11  shall  be  a 250.0  kHz  square  wave.  27.0  V peak*to-peak, 
with  a rise  and  fall  time  no  greater  than  100  nanoseconds  (ns). 

4.5 . 1 .5. 1 . 1 .3  TranafQn»«»r  onminffn  ffiprie  refection.  The  coupling  transformer 
shall  have  a common  mode  rejection  ratio  greater  than  45.0  dB  at  1.0  MHz. 

4. 5. 1.5. 1.2  Fault  isolation.  An  isolation  resistor  shall  be  placed  in  series 
with  each  connection  to  the  data  bus  cable.  This  resistor  shall  have  a value 
of  0.75  Zq  ohms  plus  or  minus  2.0  percent,  where  Zo  iv  the  selected  cable 
nominal  characteristic  Impedance.  The  Impedance  placed  across  the  data  bus 
cable  shall  be  no  less  than  1.5  Zg  ohms  for  any  failure  of  the  coupling 
transformer,  cable  stub,  or  terminal  transmitter/receiver . 

4. 5. 1.5. 1.3  Cable  coupling.  All  coupling  transformers  and  isolation 
resistors,  as  specified  In  4. 5. 1.5. 1.1  and  4. 5 .1.5. 1.2,  shall  have  continuous 
shielding  which  will  provide  a minimum  of  75  percent  coverage.  The  isolation 
resistors  and  coupling  transformers  shall  be  placed  at  minimum  possible 
distance  from  the  Junction  of  the  stub  to  the  main  bus. 

4. 5. 1.5. 1.4  Stub  voltaae  reoulrementa.  Every  data  bus  shall  be  designed  such 
that  all  stubs  at  point  A of  figure  9 shall  have  a peak-to-peak  amplitude, 
line-to-llne  within  the  range  of  1.0  and  14.0  V for  a transmission  by  any 
terminal  on  the  data  bus.  This  shall  include  the  maximum  reduction  of  data  bus 
signal  amplitude  in  the  event  that  one  of  the  terminals  has  a fault  which 
causes  it  to  reflect  a fault  impedance  specified  In  4. 5. 1.5. 1.2  on  the  data 
bus.  This  shall  also  Include  the  worse  case  output  voltage  of  the  terminals  as 
specified  in  4. 5 .2. 1.1.1  and  4. 5. 2. 2. 1.1. 

4.5. 1.5.2  DAreot  coupled  stubs.  The  length  of  a direct  coupled  stub  should 
not  exceed  1 foot.  Refer  to  10.5  for  comments  concerning  direct  coupled  stubs. 
If  a direct  coupled  stub  is  used,  then. the  following  shall  apply. 

4. 5. 1.5 .2.1  Fault  isolation.  An  Isolation  resistor  shall  be  placed  in  series 
with  each  connection  to  the  data  bus  cable.  This  resistor  shall  have  a value 
of  55.0  ohms  plus  or  minus  2.0  percent.  The  isolation  resistors  shall  be 
placed  within  the  RT  as  shown  on  figure  10. 
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PERCENT  DROOP  " § >«  100 


FIGURE  11.  Coupling  transfornar. 


FIOURE  12.  Terminal  I/O  ch.iracter  1st  Ics  for  tr.^nsformer  coupled  and  direct 
coup!  e^_^t  ul^ . 
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*».?).  1.^.2. 2 Cable  coupling.  All  bus-stub  Junctions  shall  have  continuous 
shielding  which  will  provide  a minlinuni  of  75  peivent  coverage. 

•1.5. 1.5. 2. 3 Stub  voltage  1 uoulruaent a . Kvery  data  bus  shall  be  designed  such 
that  all  .stubs  at  point  A ■)f  figure  10  shall  have  a peak-to-peak  aaplltude, 
llne-to-llne  within  the  range  of  1.4  and  2i).h  V for  a transalssion  by  any 
teralnal  on  the  data  bus.  This  shall  inoiudo  the  naxiaua  reduction  of  data 
bus  signal  aaplltude  in  the  event  that  one  of  the  teralnals  has  a fault  which 
causes  It  to  reflect  a fault  impedance  of  110  ohms  on  the  data  bus.  This  -Shall 
also  Include  the  worst  case  output  voltage  of  the  terminals  as  specified  In 

4. 5. 2. 1.1.1  and  4. 5. 2. 2. 1.1. 

*1.5. 1.5. 3 Wirlna  and  cabling  for  aiC . For  purposes  of  electroaagnetlc 
capability  (EHC),  the  wiring  and  cabling  provisions  of  MlL-E-6051  shall  apply. 

1.5.2  Tarainai  jHuggciarlaLlca  • 

4. 5. 2.1  Terminals  with  transformer  coupled  stubs. 

4. 5. 2. 1.1  Terminal  output  characteristics . The  following  characteristics 
shall  be  measured  with  Rf  shown  on  figure  12,  equal  to  70.0  ohms  ♦2.0 
percent. 

4.5.2.  1.1.1  ciutput  levels.  The  terminal  output  voltage  levels  shall  be 
measured  using  the  test  oont  Igui'ation  shown  on  t'lgiu'e  12.  The  terminal  output 
voltage  sliall  be  within  the  range  of  18.0  to  27.0  V,  peak-to-peak , 

1 tne- trv.  1 tne  , when  mea.siired  at  folnt  A on  figure  12. 

4.5.2. 1.1.2  Output  waveform.  The  waveioim,  when  measured  at  point  A on  figure 
12  shall  have  zero  crossing  deviations  which  are  equal  to,  or  less  than,  25.0 
ns  from  the  Ideal  crossing  point,  measured  with  respect  to  the  previous  zero 
orosslng  1 1 .e . , .5  1 .025  us,  1.0  ♦ .025  us,  1.5  ♦ .025  us,  and  2.0  ♦ .025  its). 
The  rise  and  fall  time  of  this  waveform  shall  he  from  100. 0 to  3OO.O  ns  when 
measured  fiMm  levels  of  10  to  40  percent  of  full  waveform  peak-to-peak, 

1 me- to- I tne  , voltage  as  shown  on  figure  13.  Any  distortion  of  the  waveform 
Including  overstwot  and  rlnglrtg  stial  1 not  exceed  1 400.0  millivolts  ImV)  p«ak , 
llne-to-llne,  as  measure»l  at  tv>tnl  A,  ftgure  12. 

4.5.2.  1.1.3  Output  noise.  Any  noise  transmitted  when  the  tennlnal  Is 
receiving  or  ha's  power  removetl,  shall  ni't  exceovl  a value  of  14.0  mV,  RMS, 

1 ine-to-1  me  , as  measured  at  ixnnt  A,  figure  12. 

4.5.2.  1.  1.4  Uutuut  svanctry.  From  !(>«>  time  beginning  2.5  us  after  the  mld-blt 
orosslng  of  the  parity  bit  of  * he  last  word  t r.m.smi  * t ed  by  a terminal,  the 
maxlmun  voltage  at  point  A of  figure  1.’  shall  be  no  greater  ttian  * 250.0  mV 
peak,  llne-to-llne.  Tins  .shall  he  tc.sted  with  t tu'  terminal  transmitting  the 
maxlmun  number  of  words  it  is  designe»i  to  transmit,  up  to  11.  This  test  shall 
be  run  six  times  with  each  word  in  a cont  igiK'u.s  blooK  of  words  having  the  same 
bit  (Vittern.  'he  six  wim\1  content.s  tfiat  r-tiall  l>e  u.sed  are  8000j(j,  7FFF'tb, 
OOOO^p,  FFFlj(,,  5555i(, , and  AAAAi^,.  The  output  of  tne  termtnal  shall  be  as 
specified  in  4.5.2.  1.1.1  an.l  4,5.2.  1.1.2. 

4.5.2.  1.2  Terminal  Inuut  characteristics.  The  fol lowing  characteristics  shall 
be  measureil  Indevietideiill  y . 
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S . ? . 1 . 1 Input  w^velofm  c>.iiqLialUii  1 1 1 y . Itie  let-tninal  stiall  be  v’^ai'able  ot 

receiving  anJ  opera'  ing  with  l(i-  incoming  signals  spi-citied  herein,  and  shall 
accept  wavel'oim  varying  Iroin  a square  wive  to  a sine  wave  with  a max  imum  zero 
crossing  deviation  1 1'om  'he  meal  with  I'e.spect  to  t tie  previous  zero  crossing  of 
1 IH)  ns,  (l.e.,  .IS  us,  .1'.  us,  1.0  i .thus,  .‘il  . lb  iJs)  . The 

teminal  shall  resixind  to  an  input  sign.il  wiiose  iieak-to-peak  amplitude, 

1 the- to- 1 tne  , is  wltliin  the  range  of  . db  to  1 *) . 0 V.  Itie  terminal  shall  not 
respond  to  an  input  signal  whose  (ieak-to-p*'aK  amplitude,  1 me- to-1  ine , Is 
within  ttie  range  of  0.0  to  .20  V.  The  voltages  are  measured  at  point  A on 
figure  9. 

11.5.2.1.2.2  Coflimon  mode  re  lections.  Any  signals  frooi  direct  current  I DC)  to 

2.0  MHz, with  cimplttudes  equal  to  or  less  ttian  t 10.0  V peak,  1 ine-to-grcund  , 
measui'ed  at  (K>int  A on  llgure  9,  shall  not  degrade  tlie  fier tormance  of  the 
rece  iver  . 

It. 5. 2.  1.2.3  Input  Impedance.  The  magnitude  of  the  terminal  Input  Impedance, 
when  the  RT  Is  not  transmitting,  or  has  power  removed,  shall  be  a alnimum  of 

1000.0  ohms  within  the  frequency  range  of  '.'5.U  khz  to  1.0  MHz.  This  impadance 
Is  that  measured  llne-to-line  at  point  A on  figure  9. 

4.5.2.1.2.11  Hciae  re  lection.  The  terminal  shall  exhibit  a maximum  word  error 
rate  of  one  part  In  10',  on  all  words  received  by  the  terminal,  after 
validation  checks  as  specified  in  4.4,  when  operating  In  the  presence  of 
additive  white  Gaussian  noise  distributed  over  a bandwidth  of  1.0  kHz  to  4.0 
MHz  at  an  RMS  amplitude  of  140  mV.  A word  error  shall  Include  any  fault  which 
causes  the  message  error  bit  to  be  set  In  the  terminal's  status  word,  or  one 
which  causes  a terminal  to  not  respond  to  a valid  command.  The  word  error  rate 
shall  be  measured  with  a 2.  1 V peak-tO'peak , 1 1'ne-to-i Ine , Input  to  the 
terminal  as  measured  at  point  A on  figure  9.  The  noise  tests  shall  ba  run 
continuously  until,  for  a particular  number  of  failures,  the  number  of  words 
received  by  the  terminal.  Including  both  command  and  data  words,  exoaeds  the 
required  number  for  acceptance  of  the  terminal,  or  Is  less  than  the  required 
number  for  rejection  of  the  terminal,  as  specified  in  table  II.  All  data  words 
used  In  the  tests  shall  contain  random  bit  patterns.  These  bit  patterns  shall 
be  unique  for  each  data  word  In  a message,  and  shall  change  randomly  from 
message  to  message . 

4. 5. 2. 2 Terminals  with  direct  coupled  stubs. 


4. 5. 2. 2.1  Terminal  output  characteristics.  The  following  characteristics 
shall  be  measured  with  R^^,  as  shown  on  figure  12,  equal  to  35.0  ohms  *2.0 
percent . 

4. 5. 2. 2. 1.1  output  levels.  The  terminal  output  voltage  levels  shall  be 
measured  using  the  test  configuration  shown  on  figure  12.  The  terminal  output 
voltage  shall  be  within  the  range  of  b.O  to  9.0  V,  peak-to-peak,  llna-to>lina, 
whan  measured  at  point  A on  figure  12. 
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Table  II.  Criteria  for  acceptance  or  reiection  of  a 
terminal  lor  tbe  nw>ise  rejection  test 

TOTAL  WORDS  HtX'tlVKD  HK  THE  TERMINAL 
( in  mul  ti  pies  ot  107  ) 


No  ot 

hejeo  t 

Accept 

Errors 

LEqual  or  less) 

Ibquai-gr.aQreJ 

0 

N/A 

4.40 

1 

N/A 

5.21 

2 

N/A 

6.  02 

3 

N/A 

6 63 

4 

N/A 

7.64 

S 

N/A 

8.4  5 

6 

.45 

9.27 

7 

1.26 

10.08 

8 

2.07 

10.  89 

9 

2.88 

1 1 . 70 

10 

3.69 

12.51 

1 1 

4.50 

1 3.32 

12 

5.  31 

14.  13 

13 

6.12 

14.94 

14 

b.  93 

15.75 

15 

7.74 

16.56 

16 

8.55. 

1 7 . 37 

17 

9.37 

18.19 

18 

10.  18 

19.00 

19 

10.99 

19.  81 

20 

11.80 

20.62 

21 

12.  61 

21.43 

22 

1 3.  42 

22.24 

23 

14.23 

23-05 

24 

15.04 

23.8b 

25 

15.85 

24.67 

26 

16.66 

25.48 

27 

17.47 

2b. 29 

28 

18.29 

27.  1 1 

29 

10.10 

27.92 

30 

19.90 

28.7  3 

31 

20.72 

29.54 

32 

21.53 

30.  35 

33 

22.34 

31.1b 

3*1 

23.  15 

3 1 . 97 

35 

2 3.9b 

32.78 

36 

24.77 

33.00 

37 

25.58 

33-00 

38 

26.  39 

33-00 

39 

27.21 

33.00 

40 

28.02 

33.00 

41 

33.00 

N/A 

28 
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9.  *) . i?.  t . i’  Uuttf9t,  ytavclorBi.  Tlie  wuvrfofm,  when  me.i:nii'<'<i  nl  point  A on  figure 
1«?,  shall  have  zpro  crossing  deviations  which  are  eijiial  to,  or  less  than,  25.0 
ns  from  the  Ideal  oixisslng  {x>lnt,  measured  with  res|x'ct  to  the  previous  zero 
crossing  (l.e.,  t .(V,  us,  1.0  t us,  l.h  ♦ .O-’S  us  and  ^.0  ♦ .025  us), 

llte  rl.se  and  fall  time  of  this  waveform  shall  be  Trom  100.0  to  3OO.fi  ns  when 
measured  frvvn  levels  of  10  to  90  percent  of  full  waveform  f>eak- to- peak  , 

1 Ine- to- 1 Ine  , voltage  as  shown  on  ttgiu'e  1).  Any  distortion  of  the  wavefonn 
including  overslH)ot  and  ringing  shall  not  exceed  ♦ 300.0  mV  iieak  , 1 ine- to-1  ine , 
as  measurevl  at  point  A on  flgiu'e  12. 


9. 5. 2. 2.  1.3  Output  noise.  Any  tml.se  transmitted  when  the  tcnninal  is 
receiving  or  Itas  ixiwer  r«>roovetl  , shall  not  exceetl  a valui'  of  S.O  mV,  HMS, 
I ine- to-1  Ine  , as  measureil  at  point  A on  ligiu'e  12. 


9. 5. 2. 2.  1.4  Output  svnunotrv.  i'rom  the  time  beginning  .’.S  us  after  the  mid-bit 
crossing  of  the  parity  bit  01  t.he  last  wiird  tran.sml  tted  by  a terminal,  the 
maximuQ  voltage  at  p»iint  A on  figure  12,  shall  be  no  greater  than  i 90.0  mV 
()eak  , 1 ine- to- 1 ine  . This  shall  be  tested  with  the  terminal  transmitting  the 
maxlmun  number  of  vxirds  it  Is  designe*!  to  transmit,  up  to  33-  This  tost  shall 
be  run  six  times  with  each  word  in  a contiguous  blor^k  of  words  havirig  the  same 
bit  pattern.  The  six  wtnxl  contents  tlrnt  shall  be  used  are  6OOO15,  7FFF15, 
0000^5,  555Sih.  bbO  AAAAk,.  The  output  of  the  terminal  shall  be  as 

specified  in  4.5.2.?. 1. I and  4. 5-2. 2. 1.2. 

4. 5. 2. 2. 2 Tcnninal  input  characteristics.  The  following  characteristics  shall 
be  measured  Indeiienden  1 1 y . 

4. 5. 2. 2. 2.1  loBUti  JUtyufUTBl  iluoifiaLiblii.Lx  ■ The  terminal  shall  be  capable  of 
receiving  and  operating  with  the  incoming  signals  specified  herein,  and  shall 
accept  waveform  varying  friim  a square  wave  to  a sine  wave  with  a maxlaua  aero 
crossing  deviation  from  the  Idc.iL  with  respect  to  the  previous  aero  crossing  of 
plus  or  minus  150  n.s,  (l.e.,  2.0  ♦ . ts  us  1.5  t . 15  us  1.0  ♦ .15  us 
.5  i .15  us).  The  terminal  shall  respond  to  an  input  signal  whose  peak-to-pealc 
amplitude,  llne-to-llne.  Is  within  the  range  of  1.2  to  20.0  V.  The  terminal 
shall  not  resp<)nd  to  an  input  signal  whose  peak-to-peak  amplitude, 
llne-to-llne.  Is  within  the  range  of  0.0  to  .28  V.  The  voltages  are  measured 
at  point  A on  figure  10. 


4. 5. 2. 2 .2.2  i^alBUlun  BUJu  . Any  signals  from  DC  to  2.0  HHx , with 

aaplltude.s  equal  to  or  l*tss  than  i 10.0  V peak,  line-to-ground,  measured  at 
point  A on  figure  10,  sh.ili  not  degrade  Ihe  performance  of  the  receiver. 

4. 5. 2. 2. 2. 3 Input  Impcdancu . The  magr\tiude  of  the  terminal  input  Impedance, 
when  the  RT  Is  not  transmt  ttlrig,  >)r  h.ts  power  removed,  shall  be  a minimum  of 
2000.0  ohms  within  the  frequeney  range  of  ■'5.0  kHz  to  1.0  MHz.  This  Impedance 
Is  that  measured  llne-to-llne  at  point  A <.'n  figure  10. 

4. 5. 2. 2. 2. 4 duiau  r.flJyqtiilU.  The  letmln.il  shall  exhibit  a maximum  word  error 
rate  of  one  part  in  10’,  on  all  w.'rJs  received  by  the  terminal,  after 
validation  checks  as  spe*->ifl«*d  in  4.4,  when  'peratlng  In  the  presence  of 
additive  white  ilaussian  noise  distributee  >vcr  a bandwidth  of  1.0  kHz  to  4.0 
MHz  at  an  RMS  amplitude  of  20ti  mV.  A w rd  error  shall  include  any  fault  which 
causes  the  message  ei'ior  bit  lo  be  set  in  the  terminal's  status  word,  or  one 
which  causes  a terminal  to  not  respt’iul  to  a valid  command.  The  word  error  rate 
shall  be  measured  with  a i.O  V peak-to-peak,  line-to-ilne,  Input  to  bha 
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terminal  as  raeasiu’ecl  at  ixjlrit  A fin  flgiu'e  10.  The  noise  tests  shall  be  run 
continuously  until,  for  a particular  niinber  of  failures,  the  nunber  of  words 
received  by  the  terminal.  Including  both  command  and  data  words,  exceeds  the 
required  nunber  for  acceptance  of  the  terminal,  or  is  less  than  the  required 
number  for  rejection  of  the  terminal,  as  specified  in  table  II.  All  data  words 
used  in  the  tests  shall  contain  random  bit  patterns.  These  bit  patterns  slhall 
be  unique  for  each  data  wal'd  In  a message,  and  shall  change  randomly  from 
message  to  message  . 

4. 6 Redundant  data  bus  reauirementfS.  if  redundant  data  buses  are  used,  the 
requirements  as  specltied  In  the  following  shall  apply  to  tliose  data  buses. 

4.6.1  Electrical  isolation.  Ail  terminals  shall  have  a minimum  of  45  dB 
isolation  between  data  buses.  Isolation  here  means  the  ratio  in  db  between  the 
output  voltage  on  the  active  data  bus  and  the  output  voltage  on  the  inactive 
data  bus.  This  shall  be  measured  using  the  test  configuration  specified  in 
4.5.2.  1.1  or  4. 5. 2-2.1  for  each  data  bus,  bach  data  bus  shall  be  alternately 
activated  with  all  measurements  being  taken  at  point  A on  figure  12  for  each 
data  bus. 

4.6.2  Single  event  failures.  All  data  buses  shall  be  routed  to  minimize  the 
possibility  that  a single  event  failure  to  a data  bus  shall  cause  the  loss  of 
more  than  that  particular  data  bus. 

4.6.3  Dual  standby  redundant  data  bus.  If  a duel  redundant  data  bus  is  used, 
then  it  shall  be  a dual  standby  redundant  data  bus  as  specified  in  the 
follovring  paragraphs. 

4-6. 3-1  Data  bus  activity.  Only  one  data  bus  can  be  active  at  any  given  time 
except  as  specified  in  4.6. 3.2. 

4.6. 3*2  Reset  data  bus  transmitter.  If  while  operating  on  a command,  a 
terminal  receives  another  valid  command,  from  either  data  bus,  it  shall  reset 
and  respond  to  the  new  command  on  the  data  bus  on  which  the  new  command  is 
received.  The  terminal  shall  respond  to  the  new  command  as  specified  In 
4.3-3-8. 

5.  DETAIL  REQUIRtWENTS  (Not  Applicable) 


r 

1 


!1 


Custodians: 

Army  - EL 
Navy  - AS 
Air  Force  - 11 


Preparing  Activity 
Air  Force  - 1 1 

Project  M1SC-0D03 


[ 

1 

L 


30 

860 


Mll.-S'llJ-lbSih 
?1  'W>nteril)pr'  I'J/rt 


U).  UfiIlS*'4ll  • !•'<’  I'l'l  lowing  p.)r'.Hgra(<liii  iti  thin  appt'iullx  at’f  pf»*3*»ftt,pd  in  oril<»r 

to  diacuna  oortain  aspect  a of  the  slaiulatM  in  a gi-netal  sense.  They  are 
Intended  to  provide  a u.ser  iit  the  .sland.ird  more  instgtit  into  the  a.spects 
disc  us  sett  . 

10.1  Hedundaiic  V . It  is  InteiuliNl  Itial.  ttiis  staiulard  tie  used  to  support  rather 
than  to  supplant  the  .systiw  de.sign  priH-ess.  however-,  it,  has  been  found, 
tlirougti  application  experience  in  various  aircraJt,  that  tlie  use  of  a du-il 
standby  i-edundanoy  tei-hnlque  is  very  desirable  lor  u.sf*  in  integrating  mission 
avionics.  Kor  this  reason,  this  reil  undano  y scheme  is  defined  in  4.b  of  tills 
standard.  None  tlie  less,  tlie  systtmi  designer  sinnild  utilize  tills  standard  as 
the  needs  of  a ivirtloular  application  dictate.  file  use  of  redundancy,  the 
degree  to  which  it  is  impl emeiiteil , and  t lie  I'orm  which  it  takes  must  be 
determined  on  an  individual  application  basis.  Hgures  10.1  and  10. i? 
lllu.strate  some  fxiasible  approaches  to  dual  reilundanoy  . Ttiose  illustrations 
are  not  Intended  to  be  inclusive,  but  ratlier  representative.  It  should  be 
noted  that  analogous  approaches  exist  for  tlie  triple  and  qu.ad  redundant  cases. 

10.2  Bu3  coiitroller.  The  bus  controller  Is  a key  part  of  the  data  bus  system. 
The  functions  of  the  tins  controller,  in  addition  to  the  Is.suance  ot  commands, 
must  include  the  constant  monitoring  of  the  data  bus  and  the  traffic  on  tiie 
bus.  It  is  envisionevl  that  most  of  the  routine  minute  details  of  bus 
monitoring  (e.g.,  parity  ctiecking,  terminal  rK)n-res|)onsr  time-out,  etc.)  will 
be  embodied  In  hardware,  wtille  the  algortttims  for  hus  control  and  decision 
making  will  reside  in  software.  It  is  also  envisioned  tiiat,  in  general,  the 
bus  controller  will  be  a general  piu'pose  airborne  cixnput.er  with  a special 
Input/output  (I/O)  to  interface  witli  the  data  bus.  it  Is  of  extreme  Importance 
In  bus  controller  design  tiiat  the  bus  controller  be  readily  able  to  accanmodate 
terminals  of  differing  protocol's  and  status  word  bits  used.  Equipment 
deslgne<l  to  MlL-STD-15b3A  will  be  in  use  for  a considerable  period  of  time; 
thus,  bus  controllers  must  be  cai>able  of  adjusting  to  their  differing  needs. 

It  la  also  Important  to  remember  tiwit  tlie  bus  controller  will  be  the  focal 
point  for  mollification  and  growth  within  the  multiplex  system,  and  thus  the 
software  must  be  written  in  such  a manner  as  to  permit  modification  with 
rel alive  ease  . 
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NOTE:  RT  - Remote  Terminal 


FIGURE  10.2.  Illustration  of  possible  redundancy. 
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10.3  Multiplex  selection  criteria.  The  selection  of  candidate  signals  for 
multiplexing  is  a function  of  the  particular  application  Involved,  and  criteria 
will  In  general  vary  from  system  to  system.  Obviously,  those  signals  which 
have  bandwidths  of  MOO  hz  or  less  are  prime  candidates  for  inclusion  on  the 
bus.  It  Is  also  obvious  that  video,  audio,  and  high  speed  parallel  digital 
signals  should  be  excluded.  The  area  of  ciuestlonahle  application  Is  usually 
between  MOO  Hz  and  3KHz  bandwidth.  The  transfer  of  these  signals  on  the  data 
bus  will  depend  heavily  upon  the  loading  of  the  bus  in  a particular 
application.  The  decision  must  be  based  on  projected  future  bus  needs  as  well 
as  the  current  loading.  Another  class  of  signals  which  In  general  are  not 
suitable  for  multiplexing  are  those  which  can  be  typified  by  a low  rate  (over  a 
mission)  but  possessing  a high  priority  or  urgency.  Examples  of  such  signals 
might  be  a nuclear  event  detector  output  or  a missile  launch  alarm  from  a 
warning  receiver.  Such  signals  are  usually  better  left  hardwired,  but  they  may 
be  accommodated  by  the  mi^ltiplex  system  if  a direct  connection  to  the  bus 
controller's  interrupt  hardware  is  used  to  trigger  a software  action  In 
response  to  the  signal . 

10. M High  reliability  requirements.  The  use  of  simple  parity  for  error 
detection  within  the  multiplex  bus  system  was  dictated  by  a compromise  between 
the  need  for  reliable  data  transmission,  system  overhead,  and  remote  terminal 
simplicity.  Theoretical  and  empirical  evidence  indicates  that  an  undetected 
bit  error  rate  of  10~^2  can  be  expected  from  a practical  multiplex  system  built 
to  this  standard.  If  a particular  signal  requires  a bit  error  rate  which  la 
better  than  that  provided  by  the  parity  checking,  then  It  is  Incunbent  upon  the 
system  designer  to  provide  the  reliability  within  the  constraints  of  the 
standard  or  to  not  Include  this  signal  within  the  multiplex  bus  system.  A 
possible  approach  In  this  case  would  be  to  have  the  signal  source  and  sink 
provide  appropriate  error  detection  and  correction  encoding/decoding  and  employ 
extra  data  words  to  transfer  the  information.  Another  approach  would  be  to 
partition  the  message,  transmit  a portion  at  a time,  and  then  verify  (by 
Interrogation)  the  proper  transfer  of  each  segment. 

10.5  Stubbing . Stubbing  is  the  metlvod  wherein  a separate  line  is  connected 
between  the  primary  data  bus  line  and  a terminal.  The  direct  connection  of  a 
stub  line  causes  a mismatch  which  appears  on  the  waveforms.  This  mismatch  can 
be  reduced  by  filtering  at  the  receiver  and  by  using  bl-phase  modulation. 

Stubs  are  often  employed  not  only  as  a convenience  in  bus  layout  but  as  a means 
of  coupling  a unit  to  the  line  in  such  a manner  that  a fault  on  the  stub  or 
teriDlnal  will  not  greatly  affect  the  transmission  line  operation.  In  this 
case,  a network  is  employed  in  the  stub  line  to  provide  isolation  from  the 
fault.  These  networks  are  also  used  for  stubs  that  are  of  such  length  that  the 
mismatch  and  reflection  degrades  bus  operation.  The  preferred  method  of 
stubbing  Is  to  use  transformer  coupled  stubs,  as  defined  vn  M. 5* 1.5.1.  This 
method  provides  the  benefits  of  DC  isolation,  increased  common  mode  protection, 
a doubling  of  effective  stub  impedance,  and  fault  isolation  for  the  entire  stub 
and  terminal.  Direct  coupled  stubs,  as  defltied  in  M. 5.  1.5.2  of  this  standard, 
should  be  avoided  if  at  all  possible.  Direct  coupled  stubs  provide  no  DC 
isolation  or  common  mode  rejection  for  the  terminal  external  to  its  subsystem. 
Further,  any  shorting  fault  between  the  subsystems  internal  Isolation  resistors 
(usually  on  a circuit  board)  and  the  main  bus  Junction  will  cause  failure  of 
that  entire  bus.  It  can  be  expected  that  when  the  direct  coupled  stub  length 
exceeds  1.6  feet,  that  it  will  begin  to  distort  the  main  bus  waveforms.  Note 
that  this  length  includes  the  cable  runs  internal  to  a given  subsystem. 
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10.6  Use  ot  Ufoailcast  optiori-  TUp  uhc  i>l  i mes.saKe  as  del'lnecl  In 

4.  3.3.6.  / of  this  slaiidanl  t eprH.s*-n1  .s  a situni  tU'atil  ilopari.iire  1 roni  the  basic 
philosophy  of  this  standard  in  that  it  is  a message  (onnat  which  does  not 
provide  positive  closed-loop  control  ol  has  tralfic;.  The  .'.ystem  designer  is 
strongly  encouraged  to  solve  any  design  problems  tlu'ough  the  use  of  the  three 
basic  message  formats  without  resorting  to  use  ol  (lie  broadcast.  If  system 
designers  do  choose  to  use  ttie  broadcast  command,  tiK'y  should  carefully 
consider  the  potential  effects  of  a missed  broadcast,  message,  and  the 
subsequent  implications  for  fault  or  error  recovery  design  In  the  remote 
terminals  and  bus  controllers. 
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INSTRUCTIONS.  Thr  purpose  of  this  form  is  to  solicit  beneficial  comments  which  will  help  achieve  pioi  ure 
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